Martin Wilck <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
