linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Shakeel Butt <shakeel.butt@linux.dev>
To: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Oliver Sang <oliver.sang@intel.com>,
	oe-lkp@lists.linux.dev,  lkp@intel.com,
	Linux Memory Management List <linux-mm@kvack.org>,
	 Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	 Michal Hocko <mhocko@kernel.org>,
	Muchun Song <muchun.song@linux.dev>,
	cgroups@vger.kernel.org,  ying.huang@intel.com,
	feng.tang@intel.com, fengwei.yin@intel.com
Subject: Re: [linux-next:master] [mm]  98c9daf5ae:  aim7.jobs-per-min -29.4% regression
Date: Fri, 19 Jul 2024 15:38:26 -0700	[thread overview]
Message-ID: <x2vfqt3frbghlxonagfx52suetu7fod7taktrc6fnt2jwmzg6l@kbdwghkf3htr> (raw)
In-Reply-To: <Zpqe6NSVBQGiS86m@google.com>

On Fri, Jul 19, 2024 at 05:14:16PM GMT, Roman Gushchin wrote:
> On Tue, Jul 16, 2024 at 03:53:25PM +0800, Oliver Sang wrote:
> > hi, Roman,
> > 
> > On Mon, Jul 15, 2024 at 10:18:39PM +0000, Roman Gushchin wrote:
> > > On Mon, Jul 15, 2024 at 10:14:31PM +0800, Oliver Sang wrote:
> > > > hi, Roman Gushchin,
> > > > 
> > > > On Fri, Jul 12, 2024 at 07:03:31PM +0000, Roman Gushchin wrote:
> > > > > On Fri, Jul 12, 2024 at 02:04:48PM +0800, kernel test robot wrote:
> > > > > > 
> > > > > > 
> > > > > > Hello,
> > > > > > 
> > > > > > kernel test robot noticed a -29.4% regression of aim7.jobs-per-min on:
> > > > > > 
> > > > > > 
> > > > > > commit: 98c9daf5ae6be008f78c07b744bcff7bcc6e98da ("mm: memcg: guard memcg1-specific members of struct mem_cgroup_per_node")
> > > > > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
> > > > > 
> > > > > Hello,
> > > > > 
> > > > > thank you for the report!
> > > > > 
> > > > > I'd expect that the regression should be fixed by the commit
> > > > > "mm: memcg: add cache line padding to mem_cgroup_per_node".
> > > > > 
> > > > > Can you, please, confirm that it's not the case?
> > > > > 
> > > > > Thank you!
> > > > 
> > > > in our this aim7 test, we found the performance partially recovered by
> > > > "mm: memcg: add cache line padding to mem_cgroup_per_node" but not fully
> > > 
> > > Thank you for providing the detailed information!
> > > 
> > > Can you, please, check if the following patch resolves the regression entirely?
> > 
> > no. in our tests, the following patch has little impact.
> > I directly apply it upon 6df13230b6 (if this is not the proper applyment, please
> > let me know, thanks)
> 
> Hm, interesting. And thank you for the confirmation, you did everything correct.
> Because the only thing the original patch did was a removal of few fields from
> the mem_cgroup_per_node struct, there are not many options left here.
> Would you mind to try the following patch?
> 
> Thank you and really appreciate your help!
> 
> 
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 7e2eb091049a..0e5bf25d324f 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -109,6 +109,7 @@ struct mem_cgroup_per_node {
> 
>         /* Fields which get updated often at the end. */
>         struct lruvec           lruvec;
> +       CACHELINE_PADDING(_pad2_);
>         unsigned long           lru_zone_size[MAX_NR_ZONES][NR_LRU_LISTS];
>         struct mem_cgroup_reclaim_iter  iter;
>  };
> 
> 

I suspect we need padding in the struct mem_cgroup instead of in struct
mem_cgroup_per_node. I am planning to run some experiments and will
report back once I have some convincing numbers.


  reply	other threads:[~2024-07-19 22:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-12  6:04 kernel test robot
2024-07-12 19:03 ` Roman Gushchin
2024-07-15 14:14   ` Oliver Sang
2024-07-15 22:18     ` Roman Gushchin
2024-07-16  7:53       ` Oliver Sang
2024-07-19 17:14         ` Roman Gushchin
2024-07-19 22:38           ` Shakeel Butt [this message]
2024-07-22 15:37             ` Roman Gushchin
2024-07-22 19:51               ` Shakeel Butt
2024-07-23  3:42           ` [linux-next:master] [mm] : " Oliver Sang
2024-07-23 15:44             ` Shakeel Butt
2024-07-24 22:15             ` Roman Gushchin

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=x2vfqt3frbghlxonagfx52suetu7fod7taktrc6fnt2jwmzg6l@kbdwghkf3htr \
    --to=shakeel.butt@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=feng.tang@intel.com \
    --cc=fengwei.yin@intel.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=mhocko@kernel.org \
    --cc=muchun.song@linux.dev \
    --cc=oe-lkp@lists.linux.dev \
    --cc=oliver.sang@intel.com \
    --cc=roman.gushchin@linux.dev \
    --cc=ying.huang@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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox