All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Tejun Heo <tj@kernel.org>, Michal Hocko <mhocko@suse.com>,
	Roman Gushchin <guro@fb.com>, Shakeel Butt <shakeelb@google.com>,
	linux-mm@kvack.org, cgroups@vger.kernel.org,
	linux-kernel@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH v3 4/8] cgroup: rstat: support cgroup1
Date: Wed, 17 Feb 2021 15:52:59 -0500	[thread overview]
Message-ID: <YC2CKyaeF2bqvpMk@cmpxchg.org> (raw)
In-Reply-To: <20210217174232.GA19239@blackbody.suse.cz>

On Wed, Feb 17, 2021 at 06:42:32PM +0100, Michal Koutný wrote:
> Hello.
> 
> On Tue, Feb 09, 2021 at 11:33:00AM -0500, Johannes Weiner <hannes@cmpxchg.org> wrote:
> > @@ -1971,10 +1978,14 @@ int cgroup_setup_root(struct cgroup_root *root, u16 ss_mask)
> >  	if (ret)
> >  		goto destroy_root;
> >  
> > -	ret = rebind_subsystems(root, ss_mask);
> > +	ret = cgroup_rstat_init(root_cgrp);
> Would it make sense to do cgroup_rstat_init() only if there's a subsys
> in ss_mask that makes use of rstat?
> (On legacy systems there could be individual hierarchy for each
> controller so the rstat space can be saved.)

It's possible, but I don't think worth the trouble.

It would have to be done from rebind_subsystems(), as remount can add
more subsystems to an existing cgroup1 root. That in turn means we'd
have to have separate init paths for cgroup1 and cgroup2.

While we split cgroup1 and cgroup2 paths where necessary in the code,
it's a significant maintenance burden and a not unlikely source of
subtle errors (see the recent 'fix swap undercounting in cgroup2').

In this case, we're talking about a relatively small data structure
and the overhead is per mountpoint. Comparatively, we're allocating
the full vmstats structures for cgroup1 groups which barely use them,
and cgroup1 softlimit tree structures for each cgroup2 group.

So I don't think it's a good tradeoff. Subtle bugs that require kernel
patches are more disruptive to the user experience than the amount of
memory in question here.

> > @@ -285,8 +285,6 @@ void __init cgroup_rstat_boot(void)
> >  
> >  	for_each_possible_cpu(cpu)
> >  		raw_spin_lock_init(per_cpu_ptr(&cgroup_rstat_cpu_lock, cpu));
> > -
> > -	BUG_ON(cgroup_rstat_init(&cgrp_dfl_root.cgrp));
> >  }
> Regardless of the suggestion above, this removal obsoletes the comment
> cgroup_rstat_init:
> 
>          int cpu;
>  
> -        /* the root cgrp has rstat_cpu preallocated */
>          if (!cgrp->rstat_cpu) {
>                  cgrp->rstat_cpu = alloc_percpu(struct cgroup_rstat_cpu);

Oh, I'm not removing the init call, I'm merely moving it from
cgroup_rstat_boot() to cgroup_setup_root().

The default root group has statically preallocated percpu data before
and after this patch. See cgroup.c:

  static DEFINE_PER_CPU(struct cgroup_rstat_cpu, cgrp_dfl_root_rstat_cpu);

  /* the default hierarchy */
  struct cgroup_root cgrp_dfl_root = { .cgrp.rstat_cpu = &cgrp_dfl_root_rstat_cpu };
  EXPORT_SYMBOL_GPL(cgrp_dfl_root);

  reply	other threads:[~2021-02-17 20:54 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-09 16:32 [PATCH v3 0/8] mm: memcontrol: switch to rstat Johannes Weiner
2021-02-09 16:32 ` Johannes Weiner
2021-02-09 16:32 ` [PATCH v3 1/8] mm: memcontrol: fix cpuhotplug statistics flushing Johannes Weiner
2021-02-09 16:32   ` Johannes Weiner
2021-02-17 17:43   ` Michal Koutný
2021-02-17 17:43     ` Michal Koutný
2021-02-09 16:32 ` [PATCH v3 2/8] mm: memcontrol: kill mem_cgroup_nodeinfo() Johannes Weiner
2021-02-09 16:32   ` Johannes Weiner
2021-02-17 17:43   ` Michal Koutný
2021-02-17 17:43     ` Michal Koutný
2021-02-09 16:32 ` [PATCH v3 3/8] mm: memcontrol: privatize memcg_page_state query functions Johannes Weiner
2021-02-09 16:32   ` Johannes Weiner
2021-02-17 17:44   ` Michal Koutný
2021-02-17 17:44     ` Michal Koutný
2021-02-09 16:33 ` [PATCH v3 4/8] cgroup: rstat: support cgroup1 Johannes Weiner
2021-02-09 16:33   ` Johannes Weiner
2021-02-17 17:42   ` Michal Koutný
2021-02-17 17:42     ` Michal Koutný
2021-02-17 20:52     ` Johannes Weiner [this message]
2021-02-18 15:45       ` Michal Koutný
2021-02-18 15:45         ` Michal Koutný
2021-02-18 17:06         ` Johannes Weiner
2021-02-09 16:33 ` [PATCH v3 5/8] cgroup: rstat: punt root-level optimization to individual controllers Johannes Weiner
2021-02-09 16:33   ` Johannes Weiner
2021-02-09 16:33 ` [PATCH v3 6/8] mm: memcontrol: switch to rstat Johannes Weiner
2021-02-09 16:33   ` Johannes Weiner
2021-02-18 15:36   ` Michal Koutný
2021-02-18 15:36     ` Michal Koutný
2021-02-09 16:33 ` [PATCH v3 7/8] mm: memcontrol: consolidate lruvec stat flushing Johannes Weiner
2021-02-09 16:33   ` Johannes Weiner
2021-02-09 20:21   ` Roman Gushchin
2021-02-09 20:21     ` Roman Gushchin
2021-02-09 16:33 ` [PATCH v3 8/8] kselftests: cgroup: update kmem test for new vmstat implementation Johannes Weiner
2021-02-09 20:17   ` Roman Gushchin
2021-02-09 20:17     ` Roman Gushchin
2021-02-18 15:37   ` Michal Koutný
2021-02-18 15:37     ` Michal Koutný

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=YC2CKyaeF2bqvpMk@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=guro@fb.com \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=mkoutny@suse.com \
    --cc=shakeelb@google.com \
    --cc=tj@kernel.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.