Re: RFC for 2.6: avoid OOM at bounce buffer storm

[Andrew Morton]

Martin Wilck <martin.wilck@xxxxxxxxxxxxxxxxxxx> wrote:
>
> Hi Andrew,
> 
> > Well.  As I said, I think what you're seeing here is recent changes to
> > mm/page-writeback.c which reduce the amount of memory which we'll permit to
> > be dirtied due to write() calls.  You'll probably find that the bounce
> > buffer problem is also fixable by reducing /proc/sys/vm/dirty_ratio in
> > 2.6.9, for the same reasons.
> > 
> > What concerns me is that there are other ways of dirtying lots of memory
> > apart from write(): namely mmap(MAP_SHARED).  If someone dirties 90% of all
> > memory via mmap() then we might again get into bounce buffer starvation.
> 
> I have tried the mmap(MAP_SHARED) method now extensively. I haven't been 
> able to come anywhere near the catastrophic situations I saw with the 
> 2.6.9 kernel, even by dirtying the full 8GB in fractions of a second.

OK, thanks.

> There was another strangeness there though: Even with the high memory 
> pressure applied, The ZONE_NORMAL free memory would never go below 
> ~300MB. When the mem pressure got too high, the kernel would rather free 
> almost slabs and start swapping than use those remaining 300M. It seems 
> to me that the new logic is a bit too conservative with ZONE_NORMAL 
> allocations.

Yes, we reserve lots of ZONE_NORMAL memory when performing GFP_HIGHMEM
allocations to avoid a weird corner case in which all of the lowmem memory
is pinned down because some application mlocked a lot of memory.

You can do

	echo 1000 > /proc/sys/vm/lowmem_reserve_ratio 

to get the old behaviour back (I do this all the time).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/