lkml.org 
[lkml]   [2000]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: More 2.2.17pre9 VM issues
On Mon, 3 Jul 2000, Stephen C. Tweedie wrote:

>Sadly, you *CANNOT* fix 2.2 this way. 2.2 still takes the inode lock
>in filemap_write_page. If you write() to a file which has dirty
>mmaped regions on 2.2, it *WILL* deadlock without kpiod.
>If you can audit NFS, ext2 and FAT, as a minimum, for safety regarding
>GFP_IO, then maybe you can make this change for 2.4. You just cannot
>do it in 2.2 as long as filemap_write_page has the inode lock.

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.

However I see that if some filesystem down() a private lock needed by the
write(shared_file) path and then it generate a page fault it may deadlock
too. So checking down() in the filesystems (and not only in the VFS) will
be necessary. Then the fs will also be free to allocate with GFP_KERNEL
even in places that may be run with some lock held. So I can also return
to allocate the buffer cache with GFP_KERNEL and that's a good thing as
far I can tell.

>My gut feeling is that mmap002 needs such a substantial fix that we
>can't afford to fix it in 2.2. The fix above certainly won't do.

Ok, but then we should drop the hacks that we have in 2.2.17pre9 to try to
fix this and declare MAP_SHARED allocations not relaible. I voted for this
at first (and that's what I did in 2.2.17pre6aa2) but I got this:

On Sat, 1 Jul 2000, Rik van Riel wrote:
>
>Date: Sat, 1 Jul 2000 07:49:24 -0300 (BRST)
>From: Rik van Riel <riel@conectiva.com.br>
>To: Andrea Arcangeli <andrea@suse.de>
>Cc: Marcelo Tosatti <marcelo@conectiva.com.br>, Alan Cox <alan@redhat.com>,
> Linux Kernel <linux-kernel@vger.rutgers.edu>
>Subject: Re: [PATCH] 2.2.17pre7 VM enhancement Re: I/O performance on
> 2.4.0-test2
>
>On Wed, 28 Jun 2000, Andrea Arcangeli wrote:
>
>> >Testing dbench with 48 clients, I got 17MB/s with 2.2.17pre9, and 21MB/sec
>> >with 2.2.17pre9 + this patch.
>> ^^^^^^^^^^^^
>> I spend an relevat effort to take all the patches separated and ordered,
>> so I'd appreciate if you could avoid to mix them.
>
>Andrea, I'd appreciate it if you could quit
>the obvious flamebaits and start looking at
>2.2 VM in a serious way.
>
>Also, 2.2 is supposed to be a stable kernel.
>We cannot make any tradeoff where we lose some
>stability for a performance gain.
>
>Rik
>--
>The Internet is not a network of computers. It is a network
>of people. That is its real strength.
>
>Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies
>http://www.conectiva.com/ http://www.surriel.com/
>
>

Marcelo told me the unstable patch he was referring to is the
00_shrink_mmap-noblock-2 patch where I dropped the stuff that tried to
avoid mmap002 to fail.

One part of the real problem is that all the VM become dirty at once
because we're not able to account for it. This is mostly a performance
issue because we should be able to handle a VM full of dirty pages. (since
if half of the memory is free and the other half is dirty we could eat the
free part in a hurry and so we could fallback in the current scenario with
all the VM dirty even when we'll fix that problem, it will be more unlkely
to happen but still possible)

But the other part of the problem is realted to shrink_mmap and kpiod.
It's not enough to make shrink_mmap smart in blocking when necessary since
kpiod seems as well involved into the problem since it won't do any write
throttling but it will return "success" unconditionally. But the page
isn't freeable yet, the buffers aren't yet been allocated and there will
be nothing to shrink in the cache even if we just returned success. If we
do some write throttling in shrink_mmap we should quite naturally do some
write throttling also in filemap_swapout, no?

>> WARNING DETAIL: in the patch I'm potentially wait_on_buffer and doing
>> ll_rw_block(WRITE) even if GFP_IO is _not_ set. This looks safe because
>> ll_rw_block won't acquire any fs/VFS lock
>
>Are you 100% sure? What if the device driver needs to make a memory
>allocation and calls try_to_free_pages()? Are you entirely certain

If it will try to do a memory allocation it will never recurse on
try_to_free_pages because PF_MEMALLOC is set.

>that there are no situations, anywhere in the kernel, where this will
>result in an extra I/O where we can't afford it? What about loop over
>NFS?

loop on top of ext2 could deadlock. This can be solved by the new logic
too (since if we have any fs lock held while doing the allocation we could
skip the wait_on_buffer/ll_rw_block and so potential
run_task_queue(&tq_disk) then). However I noticed that some usage of
GFP_BUFFER is meant really only to avoid blocking (and generating new
buffer heads in the buffer head allocation case), thus I think I was wrong
in suggesting to block even if the GFP_IO bitflag is clear.

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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.112 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site