linux-kernel - Re: [PATCH v5 00/11] per-cgroup cpu-stat

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMbhsRSAPL3P-EhD4HBChsgr66xYuEg4o2JtbFX=tz9w7RCeGQ@mail.gmail.com>
Date:	Wed, 23 Jan 2013 15:53:30 -0800
From:	Colin Cross <ccross@...gle.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Glauber Costa <glommer@...allels.com>, cgroups@...r.kernel.org,
	lkml <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Turner <pjt@...gle.com>
Subject: Re: [PATCH v5 00/11] per-cgroup cpu-stat

On Wed, Jan 23, 2013 at 3:06 PM, Tejun Heo <tj@...nel.org> wrote:
> 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?

Not exactly.  Only one "app" is ever foreground, but there are
numerous other app-like things in their own process containers that
the user is aware of, and therefore gets foreground resources.  For
example, a service that is playing music in the background may get
treated like a foreground app.  Also, a foreground app may spawn
threads and request that they run in the background, so a single
container for an app is not sufficient.

> 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.

A pure-dalvik app will spawn threads through a controlled interface
that could count threads (but still could not count threads that are
runnable vs. sleeping), but any app can use JNI to link to a native
library and use pthreads directly if it wants to.  I agree per-app
containers may have some fairness advantages between multiple apps, I
just have to figure out what it will mean for apps vs. system
services, etc

> Thanks.
>
> --
> tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/