From: Aaron Lu <aaron.lu@intel.com> To: kernel test robot <xiaolong.ye@intel.com> Cc: Tejun Heo <tj@kernel.org>, lkp@01.org, LKML <linux-kernel@vger.kernel.org>, Michal Hocko <mhocko@kernel.org>, linux-mm@kvack.org Subject: Re: [LKP] [lkp-robot] [mm, memcontrol] 309fe96bfc: vm-scalability.throughput +23.0% improvement Date: Fri, 1 Jun 2018 15:26:04 +0800 [thread overview] Message-ID: <20180601072604.GB27302@intel.com> (raw) In-Reply-To: <20180528114019.GF9904@yexl-desktop> On Mon, May 28, 2018 at 07:40:19PM +0800, kernel test robot wrote: > > Greeting, > > FYI, we noticed a +23.0% improvement of vm-scalability.throughput due to commit: > > > commit: 309fe96bfc0ae387f53612927a8f0dc3eb056efd ("mm, memcontrol: implement memory.swap.events") > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master > > in testcase: vm-scalability > on test machine: 144 threads Intel(R) Xeon(R) CPU E7-8890 v3 @ 2.50GHz with 512G memory > with following parameters: > > runtime: 300s > size: 1T > test: lru-shm > cpufreq_governor: performance > > test-description: The motivation behind this suite is to exercise functions and regions of the mm/ of the Linux kernel which are of interest to us. > test-url: https://git.kernel.org/cgit/linux/kernel/git/wfg/vm-scalability.git/ > With the patch I just sent out: "mem_cgroup: make sure moving_account, move_lock_task and stat_cpu in the same cacheline" Applying this commit on top doesn't yield 23% improvement any more, but a 6% performace drop... I found the culprit being the following one line introduced in this commit: diff --git a/mm/memcontrol.c b/mm/memcontrol.c index d90b0201a8c4..07ab974c0a49 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -6019,13 +6019,17 @@ int mem_cgroup_try_charge_swap(struct page *page, swp_entry_t entry) if (!memcg) return 0; - if (!entry.val) + if (!entry.val) { + memcg_memory_event(memcg, MEMCG_SWAP_FAIL); return 0; + } memcg = mem_cgroup_id_get_online(memcg); If I remove that memcg_memory_event() call, performance will restore. It's beyond my understanding why this code path matters since there is no swap device setup in the test machine so I don't see how possible get_swap_page() could ever be called. Still investigating...
WARNING: multiple messages have this Message-ID (diff)
From: Aaron Lu <aaron.lu@intel.com> To: lkp@lists.01.org Subject: Re: [lkp-robot] [mm, memcontrol] 309fe96bfc: vm-scalability.throughput +23.0% improvement Date: Fri, 01 Jun 2018 15:26:04 +0800 [thread overview] Message-ID: <20180601072604.GB27302@intel.com> (raw) In-Reply-To: <20180528114019.GF9904@yexl-desktop> [-- Attachment #1: Type: text/plain, Size: 1847 bytes --] On Mon, May 28, 2018 at 07:40:19PM +0800, kernel test robot wrote: > > Greeting, > > FYI, we noticed a +23.0% improvement of vm-scalability.throughput due to commit: > > > commit: 309fe96bfc0ae387f53612927a8f0dc3eb056efd ("mm, memcontrol: implement memory.swap.events") > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master > > in testcase: vm-scalability > on test machine: 144 threads Intel(R) Xeon(R) CPU E7-8890 v3 @ 2.50GHz with 512G memory > with following parameters: > > runtime: 300s > size: 1T > test: lru-shm > cpufreq_governor: performance > > test-description: The motivation behind this suite is to exercise functions and regions of the mm/ of the Linux kernel which are of interest to us. > test-url: https://git.kernel.org/cgit/linux/kernel/git/wfg/vm-scalability.git/ > With the patch I just sent out: "mem_cgroup: make sure moving_account, move_lock_task and stat_cpu in the same cacheline" Applying this commit on top doesn't yield 23% improvement any more, but a 6% performace drop... I found the culprit being the following one line introduced in this commit: diff --git a/mm/memcontrol.c b/mm/memcontrol.c index d90b0201a8c4..07ab974c0a49 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -6019,13 +6019,17 @@ int mem_cgroup_try_charge_swap(struct page *page, swp_entry_t entry) if (!memcg) return 0; - if (!entry.val) + if (!entry.val) { + memcg_memory_event(memcg, MEMCG_SWAP_FAIL); return 0; + } memcg = mem_cgroup_id_get_online(memcg); If I remove that memcg_memory_event() call, performance will restore. It's beyond my understanding why this code path matters since there is no swap device setup in the test machine so I don't see how possible get_swap_page() could ever be called. Still investigating...
next prev parent reply other threads:[~2018-06-01 7:26 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-05-28 11:40 [lkp-robot] [mm, memcontrol] 309fe96bfc: vm-scalability.throughput +23.0% improvement kernel test robot 2018-05-28 11:40 ` kernel test robot 2018-05-28 12:03 ` Michal Hocko 2018-05-28 12:03 ` Michal Hocko 2018-05-29 3:15 ` [LKP] " Lu, Aaron 2018-05-29 3:15 ` Lu, Aaron 2018-05-29 7:58 ` [LKP] " Michal Hocko 2018-05-29 7:58 ` Michal Hocko 2018-05-29 8:11 ` [LKP] " Aaron Lu 2018-05-29 8:11 ` Aaron Lu 2018-05-29 8:27 ` [LKP] " Michal Hocko 2018-05-29 8:27 ` Michal Hocko 2018-05-29 9:00 ` [LKP] " Aaron Lu 2018-05-29 9:00 ` Aaron Lu 2018-06-01 7:26 ` Aaron Lu [this message] 2018-06-01 7:26 ` Aaron Lu 2018-06-06 8:50 ` [LKP] " Aaron Lu 2018-06-06 8:50 ` Aaron Lu
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=20180601072604.GB27302@intel.com \ --to=aaron.lu@intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=lkp@01.org \ --cc=mhocko@kernel.org \ --cc=tj@kernel.org \ --cc=xiaolong.ye@intel.com \ /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.