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

[Linus Torvalds <torvalds@osdl.org>]

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.

I think your patch may in fact be fine, but quite frankly, it needs 
testing under real load with highmem.

In general, I don't _think_ we should do anything different for highmem at 
all, and we should just in general try to keep a percentage of pages 
available. Now, the percentage probably does depend on the zone: we should 
be more aggressive about more "limited" zones, ie the old 16MB DMA zone 
should probably try to keep a higher percentage of free pages around than 
the normal zone, and that in turn should probably keep a higher percentage 
of pages around than the highmem zones.

And that's not because of fragmentation so much, but simply because the 
lower zones tend to have more "desperate" users. Running out of the normal 
zone is thus a "worse" situation than running out of highmem. And we 
effectively never want to allocate from the 16MB DMA zone at all, unless 
it is our only choice.

We actually do try to do that with that "lowmem_reserve[]" logic, which 
reserves more pages in the lower zones the bigger the upper zones are (ie 
if we _only_ have memory in the low 16MB, then we don't reserve any of it, 
but if we have _tons_ of memory in the high zones, then we reserve more 
memory for the low zones and thus make the watermarks higher for them).

So the watermarking interacts with that lowmem_reserve logic, and I think 
that on HIGHMEM, you'd be screwed _twice_: first because the "pages_min" 
is limited, and second because HIGHMEM has no lowmem_reserve.

Does that make sense?

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