Hi,
On Wed, Jul 05, 2000 at 05:36:25PM +0200, Andrea Arcangeli wrote:
> >
> >But you can't afford do skip it. If I create a writable mmap and fill
> >it with as much dirty data as we have got available physical memory,
> >and then I write() a 1GB swapped-out virtual area to the same file,
> >what are you going to do to clear me some free memory for the write?
> >write(2) is an unbounded operation and you can't disable VM reclaim on
> >that file for the duration of the write.
>
> I see the above case will be not handled right by the logic I was
> proposing, but I don't see how kpiod is helping that case right now.
It's avoiding the deadlock, nothing more. What happens is that if the
deadlock situation occurs, the kpiod task may block until the write()
above happens and the inode lock is dropped, but it doesn't stop the
rest of the VM from making progress. As long as there are other,
clean or swappable pages that can be reclaimed, the VM can still stay
alive.
This is in no way a satisfactory answer, since there's no cast-iron
guarantee that these other pages can be found, especially if you have
worked hard to fill all of memory with dirty mmaped pages from the
file in question. This all comes down to the lack of VM
write-throttling. We *need* a separate swapping thread that cleans
pages as well as the thread which evicts pages, because that way, we
can both (a) measure the amount of pressure on dirty pages, and (b)
block page write faults until there are enough cleaned pages in the
system --- ie. we can do write throttling.
Without that sort of mechanism in place, all you can do is eliminate
the deadlock and hope that the rest of the VM can struggle on.
> Implementing the testcase you described above looks very worty.
Right, which is why I supported your plans to keep kpiod out of 2.4.
I don't think we can fix it for 2.2, because the changes required to
avoid the deadlock in 2.2 would become far too intrusive. In 2.4, we
can legitimately require filesystems to use GFP_IO if they hold any
internal locks (eg. the superblock lock). The i_sem lock is no longer
the problem that it was in 2.2 because filemap_write_page doesn't take
it any longer.
> >supplying its own file-write routine, then we probably need to mandate
> >the use of non-GFP_IO calls for allocations, simply to avoid deadlock.
> >The other solution --- disabling file reap --- is even more painful in
> >the case above.
>
> What do you mean exactly with "disabling file reap"?
Basically what kpiod already provides. The deadlock can be avoided
if we have some way of disabling the recovery of pages from a given
file if that file is already locked. kpiod was simply the least
intrusive way we found of providing that mechanism in 2.2.2 once the
deadlock was identified in the stable branch.
Cheers,
Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:16 EST