Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19

From: Andrew Morton
Date: Thu Nov 03 2005 - 23:42:19 EST


Linus Torvalds <torvalds@xxxxxxxx> wrote:
>
> On Thu, 3 Nov 2005, Martin J. Bligh wrote:
> >
> > Ummm. I was basing it on what we actually do now in the code, unless I
> > misread it, which is perfectly possible. Do you want this patch?
> >
> > diff -purN -X /home/mbligh/.diff.exclude linux-2.6.14/mm/page_alloc.c 2.6.14-no_water_cap/mm/page_alloc.c
> > --- linux-2.6.14/mm/page_alloc.c 2005-10-27 18:52:20.000000000 -0700
> > +++ 2.6.14-no_water_cap/mm/page_alloc.c 2005-11-03 14:36:06.000000000 -0800
> > @@ -2387,8 +2387,6 @@ static void setup_per_zone_pages_min(voi
> > min_pages = zone->present_pages / 1024;
> > if (min_pages < SWAP_CLUSTER_MAX)
> > min_pages = SWAP_CLUSTER_MAX;
> > - if (min_pages > 128)
> > - min_pages = 128;
> > zone->pages_min = min_pages;
> > } else {
> > /* if it's a lowmem zone, reserve a number of pages
>
> Ahh, you're right, there's a totally separate watermark for highmem.
>
> I think I even remember this. I may even be responsible. I know some of
> our less successful highmem balancing efforts in the 2.4.x timeframe had
> serious trouble when they ran out of highmem, and started pruning lowmem
> very very aggressively. Limiting the highmem water marks meant that it
> wouldn't do that very often.

No, that was me and Matthew Dobson, circa 2.5.71. The thinking was that
highmem is just for userspace pages and we don't need to keep the free
memory pool around for things like atomic allocations. Especially as a
proportionally-sized highmem emergency pool would be potentially hundreds of
(wasted) megabytes.

iirc, things worked ok with a highmem min_pages threshold of zero pages. Back
in 2.5.70, before everyone else broke it ;)

-
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/