From: Michal Hocko <mhocko@kernel.org> To: Mel Gorman <mgorman@techsingularity.net> Cc: David Rientjes <rientjes@google.com>, Vlastimil Babka <vbabka@suse.cz>, Linus Torvalds <torvalds@linux-foundation.org>, Andrea Arcangeli <aarcange@redhat.com>, ying.huang@intel.com, s.priebe@profihost.ag, Linux List Kernel Mailing <linux-kernel@vger.kernel.org>, alex.williamson@redhat.com, lkp@01.org, kirill@shutemov.name, Andrew Morton <akpm@linux-foundation.org>, zi.yan@cs.rutgers.edu Subject: Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression Date: Wed, 5 Dec 2018 12:43:53 +0100 [thread overview] Message-ID: <20181205114353.GH1286@dhcp22.suse.cz> (raw) In-Reply-To: <20181205104343.GZ23260@techsingularity.net> 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
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: lkp@lists.01.org Subject: Re: [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression Date: Wed, 05 Dec 2018 12:43:53 +0100 [thread overview] Message-ID: <20181205114353.GH1286@dhcp22.suse.cz> (raw) In-Reply-To: <20181205104343.GZ23260@techsingularity.net> [-- Attachment #1: Type: text/plain, Size: 2820 bytes --] 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
next prev parent reply other threads:[~2018-12-05 11:43 UTC|newest] Thread overview: 154+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-27 6:25 [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression kernel test robot 2018-11-27 6:25 ` kernel test robot 2018-11-27 17:08 ` [LKP] " Linus Torvalds 2018-11-27 17:08 ` Linus Torvalds 2018-11-27 18:17 ` [LKP] " Michal Hocko 2018-11-27 18:17 ` Michal Hocko 2018-11-27 18:21 ` [LKP] " Michal Hocko 2018-11-27 18:21 ` Michal Hocko 2018-11-27 19:05 ` [LKP] " Vlastimil Babka 2018-11-27 19:05 ` Vlastimil Babka 2018-11-27 19:16 ` [LKP] " Vlastimil Babka 2018-11-27 19:16 ` Vlastimil Babka 2018-11-27 20:57 ` [LKP] " Andrea Arcangeli 2018-11-27 20:57 ` Andrea Arcangeli 2018-11-27 22:50 ` [LKP] " Linus Torvalds 2018-11-27 22:50 ` Linus Torvalds 2018-11-28 6:30 ` [LKP] " Michal Hocko 2018-11-28 6:30 ` Michal Hocko 2018-11-28 3:20 ` [LKP] " Huang, Ying 2018-11-28 3:20 ` Huang, Ying 2018-11-28 16:48 ` [LKP] " Linus Torvalds 2018-11-28 16:48 ` Linus Torvalds 2018-11-28 18:39 ` [LKP] " Andrea Arcangeli 2018-11-28 18:39 ` Andrea Arcangeli 2018-11-28 23:10 ` [LKP] " David Rientjes 2018-11-28 23:10 ` David Rientjes 2018-12-03 18:01 ` [LKP] " Linus Torvalds 2018-12-03 18:01 ` Linus Torvalds 2018-12-03 18:14 ` [LKP] " Michal Hocko 2018-12-03 18:14 ` Michal Hocko 2018-12-03 18:19 ` [LKP] " Linus Torvalds 2018-12-03 18:19 ` Linus Torvalds 2018-12-03 18:30 ` [LKP] " Michal Hocko 2018-12-03 18:30 ` Michal Hocko 2018-12-03 18:45 ` [LKP] " Linus Torvalds 2018-12-03 18:45 ` Linus Torvalds 2018-12-03 18:59 ` [LKP] " Michal Hocko 2018-12-03 18:59 ` Michal Hocko 2018-12-03 19:23 ` [LKP] " Andrea Arcangeli 2018-12-03 19:23 ` Andrea Arcangeli 2018-12-03 20:26 ` [LKP] " David Rientjes 2018-12-03 20:26 ` David Rientjes 2018-12-03 19:28 ` [LKP] " Linus Torvalds 2018-12-03 19:28 ` Linus Torvalds 2018-12-03 20:12 ` [LKP] " Andrea Arcangeli 2018-12-03 20:12 ` Andrea Arcangeli 2018-12-03 20:36 ` [LKP] " David Rientjes 2018-12-03 20:36 ` David Rientjes 2018-12-03 22:04 ` [LKP] " Linus Torvalds 2018-12-03 22:04 ` Linus Torvalds 2018-12-03 22:27 ` [LKP] " Linus Torvalds 2018-12-03 22:27 ` Linus Torvalds 2018-12-03 22:57 ` [LKP] " David Rientjes 2018-12-03 22:57 ` David Rientjes 2018-12-04 9:22 ` [LKP] " Vlastimil Babka 2018-12-04 9:22 ` Vlastimil Babka 2018-12-04 10:45 ` [LKP] " Mel Gorman 2018-12-04 10:45 ` Mel Gorman 2018-12-05 0:47 ` [LKP] " David Rientjes 2018-12-05 0:47 ` David Rientjes 2018-12-05 9:08 ` [LKP] " Michal Hocko 2018-12-05 9:08 ` Michal Hocko 2018-12-05 10:43 ` [LKP] " Mel Gorman 2018-12-05 10:43 ` Mel Gorman 2018-12-05 11:43 ` Michal Hocko [this message] 2018-12-05 11:43 ` Michal Hocko 2018-12-05 10:06 ` [LKP] " Mel Gorman 2018-12-05 10:06 ` Mel Gorman 2018-12-05 20:40 ` [LKP] " Andrea Arcangeli 2018-12-05 20:40 ` Andrea Arcangeli 2018-12-05 21:59 ` [LKP] " David Rientjes 2018-12-05 21:59 ` David Rientjes 2018-12-06 0:00 ` [LKP] " Andrea Arcangeli 2018-12-06 0:00 ` Andrea Arcangeli 2018-12-05 22:03 ` [LKP] " Linus Torvalds 2018-12-05 22:03 ` Linus Torvalds 2018-12-05 22:12 ` [LKP] " David Rientjes 2018-12-05 22:12 ` David Rientjes 2018-12-05 23:36 ` [LKP] " Andrea Arcangeli 2018-12-05 23:36 ` Andrea Arcangeli 2018-12-05 23:51 ` [LKP] " Linus Torvalds 2018-12-05 23:51 ` Linus Torvalds 2018-12-06 0:58 ` [LKP] " Linus Torvalds 2018-12-06 0:58 ` Linus Torvalds 2018-12-06 9:14 ` MADV_HUGEPAGE vs. NUMA semantic (was: Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression) Michal Hocko 2018-12-06 9:14 ` MADV_HUGEPAGE vs. NUMA semantic (was: " Michal Hocko 2018-12-06 23:49 ` MADV_HUGEPAGE vs. NUMA semantic (was: Re: [LKP] " David Rientjes 2018-12-06 23:49 ` MADV_HUGEPAGE vs. NUMA semantic (was: " David Rientjes 2018-12-07 7:34 ` MADV_HUGEPAGE vs. NUMA semantic (was: Re: [LKP] " Michal Hocko 2018-12-07 7:34 ` MADV_HUGEPAGE vs. NUMA semantic (was: " Michal Hocko 2018-12-07 4:31 ` MADV_HUGEPAGE vs. NUMA semantic (was: Re: [LKP] " Linus Torvalds 2018-12-07 4:31 ` MADV_HUGEPAGE vs. NUMA semantic (was: " Linus Torvalds 2018-12-07 7:49 ` MADV_HUGEPAGE vs. NUMA semantic (was: Re: [LKP] " Michal Hocko 2018-12-07 7:49 ` MADV_HUGEPAGE vs. NUMA semantic (was: " Michal Hocko 2018-12-07 9:06 ` MADV_HUGEPAGE vs. NUMA semantic (was: Re: [LKP] " Vlastimil Babka 2018-12-07 9:06 ` MADV_HUGEPAGE vs. NUMA semantic (was: " Vlastimil Babka 2018-12-07 23:15 ` MADV_HUGEPAGE vs. NUMA semantic (was: Re: [LKP] " David Rientjes 2018-12-07 23:15 ` MADV_HUGEPAGE vs. NUMA semantic (was: " David Rientjes 2018-12-06 23:43 ` [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3% regression David Rientjes 2018-12-06 23:43 ` David Rientjes 2018-12-07 4:01 ` [LKP] " Linus Torvalds 2018-12-07 4:01 ` Linus Torvalds 2018-12-10 0:29 ` [LKP] " David Rientjes 2018-12-10 0:29 ` David Rientjes 2018-12-10 4:49 ` [LKP] " Andrea Arcangeli 2018-12-10 4:49 ` Andrea Arcangeli 2018-12-12 0:37 ` [LKP] " David Rientjes 2018-12-12 0:37 ` David Rientjes 2018-12-12 9:50 ` [LKP] " Michal Hocko 2018-12-12 9:50 ` Michal Hocko 2018-12-12 17:00 ` [LKP] " Andrea Arcangeli 2018-12-12 17:00 ` Andrea Arcangeli 2018-12-14 11:32 ` [LKP] " Michal Hocko 2018-12-14 11:32 ` Michal Hocko 2018-12-12 10:14 ` [LKP] " Vlastimil Babka 2018-12-12 10:14 ` Vlastimil Babka 2018-12-14 21:04 ` [LKP] " David Rientjes 2018-12-14 21:04 ` David Rientjes 2018-12-14 21:33 ` [LKP] " Vlastimil Babka 2018-12-14 21:33 ` Vlastimil Babka 2018-12-21 22:18 ` [LKP] " David Rientjes 2018-12-21 22:18 ` David Rientjes 2018-12-21 22:18 ` [LKP] " David Rientjes 2018-12-22 12:08 ` Mel Gorman 2018-12-22 12:08 ` Mel Gorman 2018-12-14 23:11 ` [LKP] " Mel Gorman 2018-12-14 23:11 ` Mel Gorman 2018-12-21 22:15 ` [LKP] " David Rientjes 2018-12-21 22:15 ` David Rientjes 2018-12-12 10:44 ` [LKP] " Andrea Arcangeli 2018-12-12 10:44 ` Andrea Arcangeli 2019-04-15 11:48 ` [LKP] " Michal Hocko 2019-04-15 11:48 ` Michal Hocko 2018-12-06 0:18 ` [LKP] " David Rientjes 2018-12-06 0:18 ` David Rientjes 2018-12-06 0:54 ` [LKP] " Andrea Arcangeli 2018-12-06 0:54 ` Andrea Arcangeli 2018-12-06 9:23 ` [LKP] " Vlastimil Babka 2018-12-06 9:23 ` Vlastimil Babka 2018-12-03 20:39 ` [LKP] " David Rientjes 2018-12-03 20:39 ` David Rientjes 2018-12-03 21:25 ` [LKP] " Michal Hocko 2018-12-03 21:25 ` Michal Hocko 2018-12-03 21:53 ` [LKP] " David Rientjes 2018-12-03 21:53 ` David Rientjes 2018-12-04 8:48 ` [LKP] " Michal Hocko 2018-12-04 8:48 ` Michal Hocko 2018-12-05 0:07 ` [LKP] " David Rientjes 2018-12-05 0:07 ` David Rientjes 2018-12-05 10:18 ` [LKP] " Michal Hocko 2018-12-05 10:18 ` Michal Hocko 2018-12-05 19:16 ` [LKP] " David Rientjes 2018-12-05 19:16 ` David Rientjes 2018-11-27 7:23 [LKP] " kernel test robot
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20181205114353.GH1286@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=aarcange@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=alex.williamson@redhat.com \ --cc=kirill@shutemov.name \ --cc=linux-kernel@vger.kernel.org \ --cc=lkp@01.org \ --cc=mgorman@techsingularity.net \ --cc=rientjes@google.com \ --cc=s.priebe@profihost.ag \ --cc=torvalds@linux-foundation.org \ --cc=vbabka@suse.cz \ --cc=ying.huang@intel.com \ --cc=zi.yan@cs.rutgers.edu \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.