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 [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]
