From: "Michal Koutný" <mkoutny@suse.com>
To: Feng Tang <feng.tang@intel.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
kernel test robot <oliver.sang@intel.com>,
Roman Gushchin <guro@fb.com>, Michal Hocko <mhocko@suse.com>,
Shakeel Butt <shakeelb@google.com>,
Balbir Singh <bsingharora@gmail.com>, Tejun Heo <tj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
lkp@lists.01.org, kernel test robot <lkp@intel.com>,
"Huang, Ying" <ying.huang@intel.com>,
Zhengjun Xing <zhengjun.xing@linux.intel.com>,
andi.kleen@intel.com
Subject: Re: [mm] 2d146aa3aa: vm-scalability.throughput -36.4% regression
Date: Mon, 30 Aug 2021 16:51:04 +0200 [thread overview]
Message-ID: <YSzwWIeapkzNElwV@blackbook> (raw)
In-Reply-To: <20210818023004.GA17956@shbuild999.sh.intel.com>
Hello Feng.
On Wed, Aug 18, 2021 at 10:30:04AM +0800, Feng Tang <feng.tang@intel.com> wrote:
> As Shakeel also mentioned, this 0day's vm-scalability doesn't involve
> any explicit mem_cgroup configurations.
If it all happens inside root memcg, there should be no accesses to the
0x10 offset since the root memcg is excluded from refcounting. (Unless
the modified cacheline is a μarch artifact. Actually, for the lack of
other ideas, I was thinking about similar cause even for non-root memcgs
since the percpu refcounting is implemented via a segment register.)
Is this still relevant? (You refer to it as 0day's vm-scalability
issue.)
By some rough estimates there could be ~10 cgroup_subsys_sets per 10 MiB
of workload, so the 128B padding gives 1e-4 relative overhead (but
presumably less in most cases). I also think it acceptable (size-wise).
Out of curiosity, have you measured impact of reshuffling the refcnt
member into the middle of the cgroup_subsys_state (keeping it distant
both from .cgroup and .parent)?
Thanks,
Michal
next prev parent reply other threads:[~2021-08-30 14:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-11 3:17 [mm] 2d146aa3aa: vm-scalability.throughput -36.4% regression kernel test robot
2021-08-11 5:59 ` Linus Torvalds
2021-08-11 20:12 ` Johannes Weiner
2021-08-12 3:19 ` Feng Tang
2021-08-16 3:28 ` Feng Tang
2021-08-16 21:41 ` Johannes Weiner
2021-08-17 2:45 ` Feng Tang
2021-08-17 16:47 ` Michal Koutný
2021-08-17 17:10 ` Shakeel Butt
2021-08-18 2:30 ` Feng Tang
2021-08-30 14:51 ` Michal Koutný [this message]
2021-08-31 6:30 ` Feng Tang
2021-08-31 9:23 ` Michal Koutný
2021-09-01 4:50 ` Feng Tang
2021-09-01 15:12 ` Andi Kleen
2021-09-02 1:35 ` Feng Tang
2021-09-02 2:23 ` Andi Kleen
2021-09-02 3:46 ` Feng Tang
2021-09-02 10:53 ` Michal Koutný
2021-09-02 13:39 ` Feng Tang
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=YSzwWIeapkzNElwV@blackbook \
--to=mkoutny@suse.com \
--cc=akpm@linux-foundation.org \
--cc=andi.kleen@intel.com \
--cc=bsingharora@gmail.com \
--cc=feng.tang@intel.com \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=lkp@lists.01.org \
--cc=mhocko@suse.com \
--cc=oliver.sang@intel.com \
--cc=shakeelb@google.com \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=ying.huang@intel.com \
--cc=zhengjun.xing@linux.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;
as well as URLs for NNTP newsgroup(s).