On Wed 05-12-18 10:43:43, Mel Gorman wrote: > On Wed, Dec 05, 2018 at 10:08:56AM +0100, Michal Hocko wrote: > > On Tue 04-12-18 16:47:23, David Rientjes wrote: > > > On Tue, 4 Dec 2018, Mel Gorman wrote: > > > > > > > What should also be kept in mind is that we should avoid conflating > > > > locality preferences with THP preferences which is separate from THP > > > > allocation latencies. The whole __GFP_THISNODE approach is pushing too > > > > hard on locality versus huge pages when MADV_HUGEPAGE or always-defrag > > > > are used which is very unfortunate given that MADV_HUGEPAGE in itself > > > > says > > > > nothing about locality -- that is the business of other madvise flags or > > > > a specific policy. > > > > > > We currently lack those other madvise modes or mempolicies: mbind() is > > > not > > > a viable alternative because we do not want to oom kill when local memory > > > is depleted, we want to fallback to remote memory. > > > > Yes, there was a clear agreement that there is no suitable mempolicy > > right now and there were proposals to introduce MPOL_NODE_RECLAIM to > > introduce that behavior. This would be an improvement regardless of THP > > because global node-reclaim policy was simply a disaster we had to turn > > off by default and the global semantic was a reason people just gave up > > using it completely. > > > > The alternative is to define a clear semantic for THP allocation > requests that are considered "light" regardless of whether that needs a > GFP flag or not. A sensible default might be > > o Allocate THP local if the amount of work is light or non-existant. > o Allocate THP remote if one is freely available with no additional work > (maybe kick remote kcompactd) > o Allocate base page local if the amount of work is light or non-existant > o Allocate base page remote if the amount of work is light or non-existant > o Do heavy work in zonelist order until a base page is allocated somewhere
I am not sure about the ordering without a deeper consideration but I thin THP should reflect the approach we have for base bages. > It's not something could be clearly expressed with either NORETRY or > THISNODE but longer-term might be saner than chopping and changing on > which flags are more important and which workload is most relevant. That > runs the risk of a revert-loop where each person targetting one workload > reverts one patch to insert another until someone throws up their hands > in frustration and just carries patches out-of-tree long-term. Fully agreed! > I'm not going to prototype something along these lines for now as > fundamentally a better compaction could cut out part of the root cause > of pain. Yes there is some ground work to be done first. -- Michal Hocko SUSE Labs
