On Tue 11-09-18 13:30:20, David Rientjes wrote: > On Tue, 11 Sep 2018, Michal Hocko wrote: [...] > > hugepage specific MPOL flags sounds like yet another step into even more > > cluttered API and semantic, I am afraid. Why should this be any > > different from regular page allocations? You are getting off-node memory > > once your local node is full. You have to use an explicit binding to > > disallow that. THP should be similar in that regards. Once you have said > > that you _really_ want THP then you are closer to what we do for regular > > pages IMHO. > > > > Saying that we really want THP isn't an all-or-nothing decision. We > certainly want to try hard to fault hugepages locally especially at task > startup when remapping our .text segment to thp, and MADV_HUGEPAGE works > very well for that. Remote hugepages would be a regression that we now > have no way to avoid because the kernel doesn't provide for it, if we were > to remove __GFP_THISNODE that this patch introduces. Why cannot you use mempolicy to bind to local nodes if you really care about the locality? > On Broadwell, for example, we find 7% slower access to remote hugepages > than local native pages. On Naples, that becomes worse: 14% slower access > latency for intrasocket hugepages compared to local native pages and 39% > slower for intersocket. So, again, how does this compare to regular 4k pages? You are going to pay for the same remote access as well. >From what you have said so far it sounds like you would like to have something like the zone/node reclaim mode fine grained for a specific mapping. If we really want to support something like that then it should be a generic policy rather than THP specific thing IMHO. As I've said it is hard to come up with a solution that would satisfy everybody but considering that the existing reports are seeing this a regression and cosindering their NUMA requirements are not so strict as yours I would tend to think that stronger NUMA requirements should be expressed explicitly rather than implicit effect of a madvise flag. We do have APIs for that. -- Michal Hocko SUSE Labs
