On Mon, 3 Jul 2000, Stephen C. Tweedie wrote:
>Hi,
>
>On Mon, Jul 03, 2000 at 06:50:45PM +0200, Andrea Arcangeli wrote:
>
>> With a new logic I now know when somebody have an fs lock held from under
>> me, thus I can skip the write in such cases.
>
>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.
write(fd, buff-in-swap, 1giga) will down() the inode->i_sem, then kpiod
will remains stuck until the write will finish. This doesn't only mean
that kpiod won't be able to flush out anything from the shared mapping,
but it also means kpiod won't be able to write out anything also from
other shared mappings that could be instead flushed, while with my logic
we could at least flush dirty pages form the other mappings.
Implementing the testcase you described above looks very worty.
>> So checking down() in the filesystems (and not only in the VFS) will
>> be necessary.
>
>Not if the fs is only being called from the page cache. If the fs is
Of course. I was thinking at the worst case, for ext2 it should be trivial
for example (just a current->fs_locks++ together with down(&i_sem) and
embedded in lock_super should be enough to support the new logic).
>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"?
Andrea
-
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