From: Roman Gushchin <roman.gushchin-fxUVXftIFDnyG1zEObXtfA@public.gmane.org>
To: Shakeel Butt <shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Cc: "Michal Hocko" <mhocko-IBi9RG/b67k@public.gmane.org>,
"Johannes Weiner"
<hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
"Muchun Song"
<songmuchun-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org>,
"Michal Koutný" <mkoutny-IBi9RG/b67k@public.gmane.org>,
"Eric Dumazet" <edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
"Soheil Hassas Yeganeh"
<soheil-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
"Feng Tang" <feng.tang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Oliver Sang"
<oliver.sang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Andrew Morton"
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
lkp-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org,
Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"Linux MM" <linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
netdev <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 2/3] mm: page_counter: rearrange struct page_counter fields
Date: Mon, 22 Aug 2022 11:27:46 -0700 [thread overview]
Message-ID: <YwPKojTHxV4PFoKn@P9FQF9L96D> (raw)
In-Reply-To: <CALvZod4whYX+0ZuCGgyKuG-Q_9d0g7N_x+=WXOeB_1TM=3Q7vg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Aug 22, 2022 at 09:04:59AM -0700, Shakeel Butt wrote:
> On Mon, Aug 22, 2022 at 8:15 AM Michal Hocko <mhocko-IBi9RG/b67k@public.gmane.org> wrote:
> >
> > On Mon 22-08-22 08:06:14, Shakeel Butt wrote:
> > [...]
> > > > > struct page_counter {
> > > > > + /*
> > > > > + * Make sure 'usage' does not share cacheline with any other field. The
> > > > > + * memcg->memory.usage is a hot member of struct mem_cgroup.
> > > > > + */
> > > > > + PC_PADDING(_pad1_);
> > > >
> > > > Why don't you simply require alignment for the structure?
> > >
> > > I don't just want the alignment of the structure. I want different
> > > fields of this structure to not share the cache line. More
> > > specifically the 'high' and 'usage' fields. With this change the usage
> > > will be its own cache line, the read-most fields will be on separate
> > > cache line and the fields which sometimes get updated on charge path
> > > based on some condition will be a different cache line from the
> > > previous two.
> >
> > I do not follow. If you make an explicit requirement for the structure
> > alignement then the first field in the structure will be guarantied to
> > have that alignement and you achieve the rest to be in the other cache
> > line by adding padding behind that.
>
> Oh, you were talking explicitly about _pad1_, yes, we can remove it
> and make the struct cache align. I will do it in the next version.
Yes, please, it caught my eyes too.
With this change:
Acked-by: Roman Gushchin <roman.gushchin-fxUVXftIFDnyG1zEObXtfA@public.gmane.org>
Also, can you, please, include the numbers on the additional memory overhead?
I think it still worth it, just think we need to include them for a record.
Thanks!
WARNING: multiple messages have this Message-ID (diff)
From: Roman Gushchin <roman.gushchin@linux.dev>
To: lkp@lists.01.org
Subject: Re: [PATCH 2/3] mm: page_counter: rearrange struct page_counter fields
Date: Mon, 22 Aug 2022 11:27:46 -0700 [thread overview]
Message-ID: <YwPKojTHxV4PFoKn@P9FQF9L96D> (raw)
In-Reply-To: <CALvZod4whYX+0ZuCGgyKuG-Q_9d0g7N_x+=WXOeB_1TM=3Q7vg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]
On Mon, Aug 22, 2022 at 09:04:59AM -0700, Shakeel Butt wrote:
> On Mon, Aug 22, 2022 at 8:15 AM Michal Hocko <mhocko@suse.com> wrote:
> >
> > On Mon 22-08-22 08:06:14, Shakeel Butt wrote:
> > [...]
> > > > > struct page_counter {
> > > > > + /*
> > > > > + * Make sure 'usage' does not share cacheline with any other field. The
> > > > > + * memcg->memory.usage is a hot member of struct mem_cgroup.
> > > > > + */
> > > > > + PC_PADDING(_pad1_);
> > > >
> > > > Why don't you simply require alignment for the structure?
> > >
> > > I don't just want the alignment of the structure. I want different
> > > fields of this structure to not share the cache line. More
> > > specifically the 'high' and 'usage' fields. With this change the usage
> > > will be its own cache line, the read-most fields will be on separate
> > > cache line and the fields which sometimes get updated on charge path
> > > based on some condition will be a different cache line from the
> > > previous two.
> >
> > I do not follow. If you make an explicit requirement for the structure
> > alignement then the first field in the structure will be guarantied to
> > have that alignement and you achieve the rest to be in the other cache
> > line by adding padding behind that.
>
> Oh, you were talking explicitly about _pad1_, yes, we can remove it
> and make the struct cache align. I will do it in the next version.
Yes, please, it caught my eyes too.
With this change:
Acked-by: Roman Gushchin <roman.gushchin@linux.dev>
Also, can you, please, include the numbers on the additional memory overhead?
I think it still worth it, just think we need to include them for a record.
Thanks!
WARNING: multiple messages have this Message-ID (diff)
From: Roman Gushchin <roman.gushchin@linux.dev>
To: Shakeel Butt <shakeelb@google.com>
Cc: "Michal Hocko" <mhocko@suse.com>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Muchun Song" <songmuchun@bytedance.com>,
"Michal Koutný" <mkoutny@suse.com>,
"Eric Dumazet" <edumazet@google.com>,
"Soheil Hassas Yeganeh" <soheil@google.com>,
"Feng Tang" <feng.tang@intel.com>,
"Oliver Sang" <oliver.sang@intel.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
lkp@lists.01.org, Cgroups <cgroups@vger.kernel.org>,
"Linux MM" <linux-mm@kvack.org>, netdev <netdev@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/3] mm: page_counter: rearrange struct page_counter fields
Date: Mon, 22 Aug 2022 11:27:46 -0700 [thread overview]
Message-ID: <YwPKojTHxV4PFoKn@P9FQF9L96D> (raw)
In-Reply-To: <CALvZod4whYX+0ZuCGgyKuG-Q_9d0g7N_x+=WXOeB_1TM=3Q7vg@mail.gmail.com>
On Mon, Aug 22, 2022 at 09:04:59AM -0700, Shakeel Butt wrote:
> On Mon, Aug 22, 2022 at 8:15 AM Michal Hocko <mhocko@suse.com> wrote:
> >
> > On Mon 22-08-22 08:06:14, Shakeel Butt wrote:
> > [...]
> > > > > struct page_counter {
> > > > > + /*
> > > > > + * Make sure 'usage' does not share cacheline with any other field. The
> > > > > + * memcg->memory.usage is a hot member of struct mem_cgroup.
> > > > > + */
> > > > > + PC_PADDING(_pad1_);
> > > >
> > > > Why don't you simply require alignment for the structure?
> > >
> > > I don't just want the alignment of the structure. I want different
> > > fields of this structure to not share the cache line. More
> > > specifically the 'high' and 'usage' fields. With this change the usage
> > > will be its own cache line, the read-most fields will be on separate
> > > cache line and the fields which sometimes get updated on charge path
> > > based on some condition will be a different cache line from the
> > > previous two.
> >
> > I do not follow. If you make an explicit requirement for the structure
> > alignement then the first field in the structure will be guarantied to
> > have that alignement and you achieve the rest to be in the other cache
> > line by adding padding behind that.
>
> Oh, you were talking explicitly about _pad1_, yes, we can remove it
> and make the struct cache align. I will do it in the next version.
Yes, please, it caught my eyes too.
With this change:
Acked-by: Roman Gushchin <roman.gushchin@linux.dev>
Also, can you, please, include the numbers on the additional memory overhead?
I think it still worth it, just think we need to include them for a record.
Thanks!
next prev parent reply other threads:[~2022-08-22 18:27 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-22 0:17 [PATCH 0/3] memcg: optimizatize charge codepath Shakeel Butt
2022-08-22 0:17 ` Shakeel Butt
2022-08-22 0:17 ` Shakeel Butt
[not found] ` <20220822001737.4120417-1-shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2022-08-22 0:17 ` [PATCH 1/3] mm: page_counter: remove unneeded atomic ops for low/min Shakeel Butt
2022-08-22 0:17 ` Shakeel Butt
2022-08-22 0:17 ` Shakeel Butt
2022-08-22 9:55 ` Michal Hocko
2022-08-22 9:55 ` Michal Hocko
[not found] ` <YwNSlZFPMgclrSCz-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2022-08-22 10:18 ` Michal Hocko
2022-08-22 10:18 ` Michal Hocko
2022-08-22 10:18 ` Michal Hocko
2022-08-22 14:55 ` Shakeel Butt
2022-08-22 14:55 ` Shakeel Butt
2022-08-22 15:20 ` Michal Hocko
2022-08-22 15:20 ` Michal Hocko
[not found] ` <YwOeocdkF/lacpKn-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2022-08-22 16:06 ` Shakeel Butt
2022-08-22 16:06 ` Shakeel Butt
2022-08-22 16:06 ` Shakeel Butt
2022-08-23 9:42 ` Michal Hocko
2022-08-23 9:42 ` Michal Hocko
2022-08-23 9:42 ` Michal Hocko
[not found] ` <20220822001737.4120417-2-shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2022-08-22 0:20 ` Soheil Hassas Yeganeh
2022-08-22 0:20 ` Soheil Hassas Yeganeh
2022-08-22 0:20 ` Soheil Hassas Yeganeh
2022-08-22 2:39 ` Feng Tang
2022-08-22 2:39 ` Feng Tang
2022-08-22 2:39 ` Feng Tang
2022-08-22 18:23 ` Roman Gushchin
2022-08-22 18:23 ` Roman Gushchin
2022-08-22 18:23 ` Roman Gushchin
2022-08-22 0:17 ` [PATCH 2/3] mm: page_counter: rearrange struct page_counter fields Shakeel Butt
2022-08-22 0:17 ` Shakeel Butt
[not found] ` <20220822001737.4120417-3-shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2022-08-22 0:24 ` Soheil Hassas Yeganeh
2022-08-22 0:24 ` Soheil Hassas Yeganeh
2022-08-22 0:24 ` Soheil Hassas Yeganeh
2022-08-22 4:55 ` Shakeel Butt
2022-08-22 4:55 ` Shakeel Butt
2022-08-22 13:06 ` Soheil Hassas Yeganeh
2022-08-22 13:06 ` Soheil Hassas Yeganeh
2022-08-22 2:10 ` Feng Tang
2022-08-22 2:10 ` Feng Tang
2022-08-22 2:10 ` Feng Tang
2022-08-22 4:59 ` Shakeel Butt
2022-08-22 4:59 ` Shakeel Butt
2022-08-22 4:59 ` Shakeel Butt
2022-08-22 10:23 ` Michal Hocko
2022-08-22 10:23 ` Michal Hocko
2022-08-22 10:23 ` Michal Hocko
2022-08-22 15:06 ` Shakeel Butt
2022-08-22 15:06 ` Shakeel Butt
[not found] ` <CALvZod5pw_7hnH44hdC3rDGQxQB2XATrViNNGosG3FnUoWo-4A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-08-22 15:15 ` Michal Hocko
2022-08-22 15:15 ` Michal Hocko
2022-08-22 15:15 ` Michal Hocko
2022-08-22 16:04 ` Shakeel Butt
2022-08-22 16:04 ` Shakeel Butt
[not found] ` <CALvZod4whYX+0ZuCGgyKuG-Q_9d0g7N_x+=WXOeB_1TM=3Q7vg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2022-08-22 18:27 ` Roman Gushchin [this message]
2022-08-22 18:27 ` Roman Gushchin
2022-08-22 18:27 ` Roman Gushchin
2022-08-22 0:17 ` [PATCH 3/3] memcg: increase MEMCG_CHARGE_BATCH to 64 Shakeel Butt
2022-08-22 0:17 ` Shakeel Butt
2022-08-22 2:30 ` Feng Tang
2022-08-22 2:30 ` Feng Tang
[not found] ` <20220822001737.4120417-4-shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2022-08-22 0:24 ` Soheil Hassas Yeganeh
2022-08-22 0:24 ` Soheil Hassas Yeganeh
2022-08-22 0:24 ` Soheil Hassas Yeganeh
2022-08-22 10:47 ` Michal Hocko
2022-08-22 10:47 ` Michal Hocko
2022-08-22 10:47 ` Michal Hocko
2022-08-22 15:09 ` Shakeel Butt
2022-08-22 15:09 ` Shakeel Butt
2022-08-22 15:22 ` Michal Hocko
2022-08-22 15:22 ` Michal Hocko
[not found] ` <YwOfP/6PtS8BxNhz-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2022-08-22 16:07 ` Shakeel Butt
2022-08-22 16:07 ` Shakeel Butt
2022-08-22 16:07 ` Shakeel Butt
2022-08-22 18:37 ` Roman Gushchin
2022-08-22 18:37 ` Roman Gushchin
2022-08-22 18:37 ` Roman Gushchin
2022-08-22 19:34 ` Michal Hocko
2022-08-22 19:34 ` Michal Hocko
2022-08-22 19:34 ` Michal Hocko
[not found] ` <YwPZ1lpJ98pZSLmw-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2022-08-23 2:22 ` Roman Gushchin
2022-08-23 2:22 ` Roman Gushchin
2022-08-23 2:22 ` Roman Gushchin
2022-08-23 4:49 ` Michal Hocko
2022-08-23 4:49 ` Michal Hocko
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=YwPKojTHxV4PFoKn@P9FQF9L96D \
--to=roman.gushchin-fxuvxftifdnyg1zeobxtfa@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=feng.tang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=lkp-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org \
--cc=mhocko-IBi9RG/b67k@public.gmane.org \
--cc=mkoutny-IBi9RG/b67k@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=oliver.sang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=shakeelb-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=soheil-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=songmuchun-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org \
/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 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.