Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19
From: Linus Torvalds <torvalds@osdl.org>
Date: 2005-11-03 23:16:55
Also in:
lkml
On Thu, 3 Nov 2005, Martin J. Bligh wrote:
quoted hunk ↗ jump to hunk
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, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>