From: Tejun Heo <tj@kernel.org>
To: Colin Cross <ccross@google.com>
Cc: Glauber Costa <glommer@parallels.com>,
cgroups@vger.kernel.org, lkml <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Turner <pjt@google.com>
Subject: Re: [PATCH v5 00/11] per-cgroup cpu-stat
Date: Wed, 23 Jan 2013 15:06:08 -0800 [thread overview]
Message-ID: <20130123230608.GJ2373@mtj.dyndns.org> (raw)
In-Reply-To: <CAMbhsRRj9svWubn01wb+f=jSwVWC5u7DqJ5c8P23vAp0E2L8Rg@mail.gmail.com>
Hello, Collin.
On Wed, Jan 23, 2013 at 02:41:46PM -0800, Colin Cross wrote:
> I think some of it is just historic, we previously did not group
> application threads in the scheduler, so it would cause a change in
> behavior if we started grouping them. I will investigate switching to
> a co-mounted hierarchy so hopefully you can deprecate cpuacct in the
> future.
Yeah, it's gonna be many years, if ever, before we can actually
deprecate cpuacct and multiple hierarchies but it would be really nice
to move at least popular uses away from them sooner than later.
Also, maybe I'm misunderstanding what you were saying but isn't it the
case that only single application is "foreground" in at least vanilla
android? Maybe multi-window support is scheduled for future releases
but it wouldn't count as behavior change in that case, right?
At any rate, IMHO, it's simply the better and correct to not depend on
the number of threads in use as a measure of CPU resource
distribution.
> We can't factor the number of threads into the policy decision,
> because it depends on how many threads are runnable at any time in any
> particular application, and we have no way to track that. It would
> have to be a cgroup scheduler feature.
My understanding of android is very limited but the number of threads
in dalvik apps are controlled by the base system rather than
application itself, no? If so, factoring that into scheduling params
shouldn't be difficult. For native processes, if the number of
threads just *have* to be factored in some way, we can resort to
sampling. That said, as native apps can easily thread-bomb out of
fairness, there are way more reasons to avoid basing the resource
policy decision on the number of threads in use.
Thanks.
--
tejun
next prev parent reply other threads:[~2013-01-23 23:06 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-09 11:45 Glauber Costa
2013-01-09 11:45 ` [PATCH v5 01/11] don't call cpuacct_charge in stop_task.c Glauber Costa
2013-01-09 11:45 ` [PATCH v5 02/11] cgroup: implement CFTYPE_NO_PREFIX Glauber Costa
2013-01-09 11:45 ` [PATCH v5 03/11] cgroup, sched: let cpu serve the same files as cpuacct Glauber Costa
2013-01-14 8:34 ` Sha Zhengju
2013-01-14 14:55 ` Glauber Costa
2013-01-15 10:19 ` Sha Zhengju
2013-01-15 17:52 ` Glauber Costa
2013-01-09 11:45 ` [PATCH v5 04/11] cgroup, sched: deprecate cpuacct Glauber Costa
2013-01-09 11:45 ` [PATCH v5 05/11] sched: adjust exec_clock to use it as cpu usage metric Glauber Costa
2013-01-09 11:45 ` [PATCH v5 06/11] cpuacct: don't actually do anything Glauber Costa
2013-01-09 11:45 ` [PATCH v5 07/11] account guest time per-cgroup as well Glauber Costa
2013-01-09 11:45 ` [PATCH v5 08/11] sched: Push put_prev_task() into pick_next_task() Glauber Costa
2013-01-09 11:45 ` [PATCH v5 09/11] record per-cgroup number of context switches Glauber Costa
2013-01-09 11:45 ` [PATCH v5 10/11] sched: change nr_context_switches calculation Glauber Costa
2013-01-09 11:45 ` [PATCH v5 11/11] sched: introduce cgroup file stat_percpu Glauber Costa
2013-01-09 20:42 ` Andrew Morton
2013-01-09 21:10 ` Glauber Costa
2013-01-09 21:17 ` Andrew Morton
2013-01-09 21:27 ` Glauber Costa
2013-01-23 14:26 ` Glauber Costa
2013-01-23 14:20 ` Glauber Costa
2013-01-09 14:41 ` [PATCH v5 00/11] per-cgroup cpu-stat Tejun Heo
2013-01-16 0:33 ` Colin Cross
2013-01-21 12:14 ` Glauber Costa
2013-01-23 1:02 ` Tejun Heo
2013-01-23 1:53 ` Colin Cross
2013-01-23 8:12 ` Glauber Costa
2013-01-23 16:56 ` Tejun Heo
2013-01-23 22:41 ` Colin Cross
2013-01-23 23:06 ` Tejun Heo [this message]
2013-01-23 23:53 ` Colin Cross
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=20130123230608.GJ2373@mtj.dyndns.org \
--to=tj@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=ccross@google.com \
--cc=cgroups@vger.kernel.org \
--cc=glommer@parallels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pjt@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®