Hi,
On Mon, Jul 03, 2000 at 04:40:37PM +0200, Andrea Arcangeli wrote:
> On Mon, 3 Jul 2000, Andrea Arcangeli wrote:
>
> >--- 2.2.17pre9/fs/ext2/super.c Mon Jan 17 16:44:42 2000
> >+++ /tmp/p Mon Jul 3 13:20:12 2000
> I dropped kpiod and I applied the above patch and as I expected mmap002
> stopped running out of memory and it seems to work.
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.
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.
> 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
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?
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:12 EST