Messages in this thread | | | Date | Mon, 3 Jul 2000 18:50:45 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: 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/
| |