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

[Martin J. Bligh]

> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/