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