On Wed, Jan 23, 2013 at 3:06 PM, Tejun Heo <tj@xxxxxxxxxx> 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 cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
