Messages in this thread | | | Date | Thu, 3 Nov 2005 20:39:58 -0800 | From | Andrew Morton <> | Subject | Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 |
| |
Linus Torvalds <torvalds@osdl.org> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |