From: Frederic Weisbecker <fweisbec@gmail.com>
To: Paul Menage <menage@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Li Zefan <lizf@cn.fujitsu.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Aditya Kali <adityakali@google.com>
Subject: Re: [PATCH 7/7] cgroups: Add a max number of tasks subsystem
Date: Thu, 28 Jul 2011 17:06:24 +0200 [thread overview]
Message-ID: <20110728150620.GJ11820@somewhere.redhat.com> (raw)
In-Reply-To: <CAJniumW7ZKLLDaXSZ4TZ_=PX0ARERTeEyL-iTir12hciOArJqA@mail.gmail.com>
On Mon, Jul 25, 2011 at 06:17:08PM -0700, Paul Menage wrote:
> On Mon, Jul 11, 2011 at 7:15 AM, Frederic Weisbecker <fweisbec@gmail.com> wrote:
> > /* */
> > +
> > +#ifdef CONFIG_CGROUP_MAX_TASKS
> > +SUBSYS(max_tasks)
> > +#endif
>
> I think I'd be inclined to make the naming slightly (IMO) cleaner:
> call the subsystem 'tasks' and the files 'limit' and 'count' (or maybe
> 'usage' to be more in line with memcg).
Sure. Will rename.
> >
> > +config CGROUP_MAX_TASKS
> > + bool "Control max number of tasks in a cgroup"
> > + depends on RESOURCE_COUNTERS
> > + help
> > + This option let the user to set up an upper bound allowed number
> > + of tasks.
> > +
>
> Needs to depend on CGROUPS too?
>
> > +
> > +
> > +struct task_counter {
> > + struct res_counter res;
> > + struct cgroup_subsys_state css;
> > +};
>
> All other CSS structures put the "css" field as the first thing in the
> structure. Not sure that anything relies on that, but consistency
> can't hurt and it probably makes the code fractionally smaller since
> the translation between CSS and task_counter becomes a no-op.
I guess Li responded to the two above points.
> > +static void task_counter_exit(struct cgroup_subsys *ss, struct cgroup *cgrp,
> > + struct cgroup *old_cgrp, struct task_struct *task)
> > +{
> > + struct task_counter *cnt = cgroup_task_counter(old_cgrp);
> > +
> > + if (cnt != &root_counter)
> > + res_counter_uncharge_until(&cnt->res, &root_counter.res, 1);
> > +}
>
> Do we even need the root_counter to be exposed in any way? Why not
> make children of the root cgroup just have a NULL parent res_counter?
>
> You'll still need a task_counter object so that the cgroups framework
> has a CSS object for cgroups housekeeping, but I don't think it needs
> to actually be used for anything.
>
> Paul
Right, will try to get that.
Thanks.
next prev parent reply other threads:[~2011-07-28 15:06 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-11 14:14 [PATCH 0/7] cgroups: New max number of tasks subsystem (was: cgroups rlim subsystem) Frederic Weisbecker
2011-07-11 14:15 ` [PATCH 1/7] cgroups: Add res_counter_write_u64() API Frederic Weisbecker
2011-07-11 20:30 ` Paul Menage
2011-07-11 14:15 ` [PATCH 2/7] cgroups: New resource counter inheritance API Frederic Weisbecker
2011-07-11 20:41 ` Paul Menage
2011-07-13 12:34 ` Frederic Weisbecker
2011-07-11 14:15 ` [PATCH 3/7] cgroups: Add previous cgroup in can_attach_task/attach_task callbacks Frederic Weisbecker
2011-07-11 20:42 ` Paul Menage
2011-07-11 14:15 ` [PATCH 4/7] cgroups: New cancel_attach_task subsystem callback Frederic Weisbecker
2011-07-26 0:57 ` Paul Menage
2011-07-11 14:15 ` [PATCH 5/7] cgroups: Ability to stop res charge propagation on bounded ancestor Frederic Weisbecker
2011-07-12 0:11 ` KAMEZAWA Hiroyuki
2011-07-13 13:50 ` Frederic Weisbecker
2011-07-26 0:50 ` Paul Menage
2011-07-11 14:15 ` [PATCH 6/7] cgroups: Add res counter common ancestor searching Frederic Weisbecker
2011-07-26 1:05 ` Paul Menage
2011-07-28 14:54 ` Frederic Weisbecker
2011-07-11 14:15 ` [PATCH 7/7] cgroups: Add a max number of tasks subsystem Frederic Weisbecker
2011-07-26 1:17 ` Paul Menage
2011-07-26 1:25 ` Li Zefan
2011-07-28 15:06 ` Frederic Weisbecker [this message]
2011-07-11 14:26 ` [PATCH 0/7] cgroups: New max number of tasks subsystem (was: cgroups rlim subsystem) Frederic Weisbecker
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=20110728150620.GJ11820@somewhere.redhat.com \
--to=fweisbec@gmail.com \
--cc=adityakali@google.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=menage@google.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 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.