>> As long as we stay in safe zone boundaries you get a benefit in most >> scenarios. As soon as we would have a (temporary) workload that would >> require more unmovable allocations we would fallback to polluting some >> pageblocks only. > > The idea would work well until unmoveable pages begin to overflow into > ZONE_PREFER_MOVABLE or we move the boundary of ZONE_PREFER_MOVABLE to > avoid unmoveable page overflow. The issue comes from the lifetime of > the unmoveable pages. Since some long-live ones can be around the boundary, > there is no guarantee that ZONE_PREFER_MOVABLE cannot grow back > even if other unmoveable pages are deallocated. Ultimately, > ZONE_PREFER_MOVABLE would be shrink to a small size and the situation is > back to what we have now. As discussed this would not happen in the usual case in case we size it reasonable. Of course, if you push it to the extreme (which was never suggested!), you would create mess. There is always a way to create a mess if you abuse such mechanism. Also see Rik's reply regarding reclaim. > > OK. I have a stupid question here. Why not just grow pageblock to a larger > size, like 1GB? So the fragmentation of unmoveable pages will be at larger > granularity. But it is less likely unmoveable pages will be allocated at > a movable pageblock, since the kernel has 1GB pageblock for them after > a pageblock stealing. If other kinds of pageblocks run out, moveable and > reclaimable pages can fall back to unmoveable pageblocks. > What am I missing here? Oh no. For example pageblocks have to completely fit into a single section (that's where metadata is maintained). Please refrain from suggesting to increase the section size ;) There is plenty of code relying on pageblocks/MAX_ORDER - 1 to be reasonable in size. Examples in VMs are free page reporting or virtio-mem. -- Thanks, David / dhildenb
