linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Tejun Heo <tj@kernel.org>
Cc: Glauber Costa <glommer@parallels.com>,
	linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
	linux-mm@kvack.org, davej@redhat.com, ben@decadent.org.uk,
	pjt@google.com, lennart@poettering.net, kay.sievers@vrfy.org
Subject: Re: [RFC 0/5] forced comounts for cgroups.
Date: Wed, 05 Sep 2012 12:04:47 +0200	[thread overview]
Message-ID: <1346839487.2600.24.camel@twins> (raw)
In-Reply-To: <20120905093204.GL3195@dhcp-172-17-108-109.mtv.corp.google.com>

On Wed, 2012-09-05 at 02:32 -0700, Tejun Heo wrote:
> Hey, again.
> 
> On Wed, Sep 05, 2012 at 11:06:33AM +0200, Peter Zijlstra wrote:
> > Doing all this runtime is just going to make the mess even bigger,
> > because now we have to deal with even more stupid cases.
> > 
> > So either we go and try to contain this mess as proposed by Glauber or
> > we go delete controllers.. I've had it with this crap.
> 
> cpuacct is rather unique tho.  I think it's gonna be silly whether the
> hierarchy is unified or not.
> 
> 1. If they always can live on the exact same hierarchy, there's no
>    point in having the two separate.  Just merge them.
> 
> 2. If they need differing levels of granularity, they either need to
>    do it completely separately as they do now or have some form of
>    dynamic optimization if absolutely necesary.
> 
> So, I think that choice is rather separate from other issues.  If
> cpuacct is gonna be kept, I'd just keep it separate and warn that it
> incurs extra overhead for the current users if for nothing else.
> Otherwise, kill it or merge it into cpu.

Quite, hence my 'proposal' to remove cpuacct.

There was some whining last time Glauber proposed this, but the one
whining never convinced and has gone away from Linux, so lets just do
this.

Lets make cpuacct print a deprecated msg to dmesg for a few releases and
make cpu do all this.

The co-mounting stuff would have been nice for cpusets as well, knowing
all your tasks are affine to a subset of cpus allows for a few
optimizations (smaller cpumask iterations), but I guess we'll have to do
that dynamically, we'll just have to see how ugly that is.



  reply	other threads:[~2012-09-05 10:05 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-04 14:18 [RFC 0/5] forced comounts for cgroups Glauber Costa
2012-09-04 14:18 ` [RFC 1/5] cgroup: allow some comounts to be forced Glauber Costa
2012-09-04 14:18 ` [RFC 2/5] sched: adjust exec_clock to use it as cpu usage metric Glauber Costa
2012-09-04 14:18 ` [RFC 3/5] sched: do not call cpuacct_charge when cpu and cpuacct are comounted Glauber Costa
2012-09-04 14:18 ` [RFC 4/5] cpuacct: do not gather cpuacct statistics when not mounted Glauber Costa
2012-09-04 14:18 ` [RFC 5/5] sched: add cpusets to comounts list Glauber Costa
2012-09-04 21:46 ` [RFC 0/5] forced comounts for cgroups Tejun Heo
2012-09-05  8:03   ` Glauber Costa
2012-09-05  8:14     ` Tejun Heo
2012-09-05  8:17       ` Glauber Costa
2012-09-05  8:29         ` Tejun Heo
2012-09-05  8:35           ` Glauber Costa
2012-09-05  8:47             ` Tejun Heo
2012-09-05  8:55               ` Glauber Costa
2012-09-05  9:07                 ` Tejun Heo
2012-09-05  9:06                   ` Glauber Costa
2012-09-05  9:14                     ` Tejun Heo
2012-09-05  9:06               ` Peter Zijlstra
2012-09-05  9:07                 ` Peter Zijlstra
2012-09-05  9:22                   ` Tejun Heo
2012-09-05  9:11                 ` Tejun Heo
2012-09-05  9:12                   ` Glauber Costa
2012-09-05  9:19                     ` Tejun Heo
2012-09-05  9:30                       ` Glauber Costa
2012-09-05  9:26                     ` Peter Zijlstra
2012-09-05  9:31                       ` Glauber Costa
2012-09-05  9:45                         ` Tejun Heo
2012-09-05  9:48                           ` Glauber Costa
2012-09-05  9:56                             ` Tejun Heo
2012-09-05 10:20                         ` Peter Zijlstra
2012-09-06 20:38                           ` Tejun Heo
2012-09-06 22:39                             ` Glauber Costa
2012-09-06 22:45                               ` Tejun Heo
2012-09-05  9:32                 ` Tejun Heo
2012-09-05 10:04                   ` Peter Zijlstra [this message]
2012-09-06 20:46                     ` Tejun Heo
2012-09-06 21:11                       ` Paul Turner
2012-09-06 22:36                         ` Glauber Costa
2012-09-08 13:36                         ` Dhaval Giani

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=1346839487.2600.24.camel@twins \
    --to=a.p.zijlstra@chello.nl \
    --cc=ben@decadent.org.uk \
    --cc=cgroups@vger.kernel.org \
    --cc=davej@redhat.com \
    --cc=glommer@parallels.com \
    --cc=kay.sievers@vrfy.org \
    --cc=lennart@poettering.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pjt@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 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).