On 09.09.20 15:19, Rik van Riel wrote: > On Wed, 2020-09-09 at 09:04 +0200, Michal Hocko wrote: >> On Tue 08-09-20 10:41:10, Rik van Riel wrote: >>> On Tue, 2020-09-08 at 16:35 +0200, Michal Hocko wrote: >>> >>>> A global knob is insufficient. 1G pages will become a very >>>> precious >>>> resource as it requires a pre-allocation (reservation). So it >>>> really >>>> has >>>> to be an opt-in and the question is whether there is also some >>>> sort >>>> of >>>> access control needed. >>> >>> The 1GB pages do not require that much in the way of >>> pre-allocation. The memory can be obtained through CMA, >>> which means it can be used for movable 4kB and 2MB >>> allocations when not >>> being used for 1GB pages. >> >> That CMA has to be pre-reserved, right? That requires a >> configuration. > > To some extent, yes. > > However, because that pool can be used for movable > 4kB and 2MB > pages as well as for 1GB pages, it would be easy to just set > the size of that pool to eg. 1/3 or even 1/2 of memory for every > system. > > It isn't like the pool needs to be the exact right size. We > just need to avoid the "highmem problem" of having too little > memory for kernel allocations. > I am not sure I like the trend towards CMA that we are seeing, reserving huge buffers for specific users (and eventually even doing it automatically). What we actually want is ZONE_MOVABLE with relaxed guarantees, such that anybody who requires large, unmovable allocations can use it. I once played with the idea of having ZONE_PREFER_MOVABLE, which a) Is the primary choice for movable allocations b) Is allowed to contain unmovable allocations (esp., gigantic pages) c) Is the fallback for ZONE_NORMAL for unmovable allocations, instead of running out of memory If someone messes up the zone ratio, issues known from zone imbalances are avoided - large allocations simply become less likely to succeed. In contrast to ZONE_MOVABLE, memory offlining is not guaranteed to work. -- Thanks, David / dhildenb
