On Mon, 27 Jan 2003, Andrew Morton wrote:
>
> I suspect what is happening is that you've managed to find a code path in
> which the kernel is allocating lots of memory in a mode in which it cannot
> run effective page reclaim. This would be more likely to be true if you only
> see the failures when writing.
>
> It would help if you could change mm/vmscan.c:try_to_free_pages_zone()
> thusly:
>
> /*
> * Hmm.. Cache shrink failed - time to kill something?
> * Mhwahahhaha! This is the part I really like. Giggle.
> */
> + show_stack(0);
> out_of_memory();
> return 0;
> }
>
> and pass the resulting log output through ksyoops.
>
> And here's a protopatch to teach the kernel to make sure that there's a
> decent amount of free memory before it goes and performs GFP_NOFS pagecache
> allocations:
>
> diff -puN fs/buffer.c~a fs/buffer.c
> --- 24/fs/buffer.c~a 2003-01-27 12:28:02.000000000 -0800
> +++ 24-akpm/fs/buffer.c 2003-01-27 12:28:23.000000000 -0800
> @@ -2112,6 +2112,8 @@ int generic_direct_IO(int rw, struct ino
> for (i = 0; i < nr_blocks; i++, blocknr++) {
> struct buffer_head bh;
>
> + try_to_free_pages(GFP_KERNEL);
> +
> bh.b_state = 0;
> bh.b_dev = inode->i_dev;
> bh.b_size = blocksize;
>
>
> If that sheds no light, please send me the app and I'll see if I can
> reproduce it. Thanks.
>
>
I have not yet tried that because of the lack of time. Instead I installed
2.4.21-pre4. The problem seems to be fixed there.
Roman
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Feb 07 2003 - 22:00:14 EST