Messages in this thread | | | Date | Thu, 03 Nov 2005 15:39:36 -0800 | From | "Martin J. Bligh" <> | Subject | Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 |
| |
> 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.
Hmm. it strikes me that there will be few (if any?) allocations out of highmem. PPC64 et al dump everything into ZONE_DMA though - so those should be uncapped already.
> 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.
Well it's not 16MB on the other platforms, but ...
> 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?
Yes. So we were only capping highmem before, now I squint at it closer. I was going off a simplification I'd written for a paper, which is not generally correct. I doubt frag is a problem in highmem, so maybe the code is correct as-is. We only want contig allocs for virtual when it's mapped 1-1 to physical (ie the kernel mapping) or real physical things.
I suppose I could write something to trawl the source tree to check that assumption, but it feels right ...
M. - 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/
| |