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 -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
