On Wed, Jan 23, 2013 at 3:06 PM, Tejun Heo [off-list ref] wrote:

Hello, Collin.

On Wed, Jan 23, 2013 at 02:41:46PM -0800, Colin Cross wrote:

quoted

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.

quoted

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