On 04/27/2017 05:06 PM, Michal Hocko wrote: > On Tue 25-04-17 12:42:57, Joonsoo Kim wrote: >> On Mon, Apr 24, 2017 at 03:09:36PM +0200, Michal Hocko wrote: >>> On Mon 17-04-17 11:02:12, Joonsoo Kim wrote: >>>> On Thu, Apr 13, 2017 at 01:56:15PM +0200, Michal Hocko wrote: >>>>> On Wed 12-04-17 10:35:06, Joonsoo Kim wrote: > [...] >>> not for free. For most common configurations where we have ZONE_DMA, >>> ZONE_DMA32, ZONE_NORMAL and ZONE_MOVABLE all the 3 bits are already >>> consumed so a new zone will need a new one AFAICS. >> >> Yes, it requires one more bit for a new zone and it's handled by the patch. > > I am pretty sure that you are aware that consuming new page flag bits > is usually a no-go and something we try to avoid as much as possible > because we are in a great shortage there. So there really have to be a > _strong_ reason if we go that way. My current understanding that the > whole zone concept is more about a more convenient implementation rather > than a fundamental change which will solve unsolvable problems with the > current approach. More on that below. I don't see it as such a big issue. It's behind a CONFIG option (so we also don't need the jump labels you suggest later) and enabling it reduces the number of possible NUMA nodes (not page flags). So either you are building a kernel for android phone that needs CMA but will have a single NUMA node, or for a large server with many nodes that won't have CMA. As long as there won't be large servers that need CMA, we should be fine (yes, I know some HW vendors can be very creative, but then it's their problem?). > [...] >> MOVABLE allocation will fallback as following sequence. >> >> ZONE_CMA -> ZONE_MOVABLE -> ZONE_HIGHMEM -> ZONE_NORMAL -> ... Hmm, so this in effect resembles some of the aggressive CMA utilization efforts that were never merged due to issues. Joonsoo, could you summarize/expand the cover letter part on what were the issues with aggressive CMA utilization, and why they no longer apply with ZONE_CMA, especially given the current node-lru reclaim? Thanks. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
