Hey, Mike. On Thu, Aug 20, 2015 at 06:00:59AM +0200, Mike Galbraith wrote: > If create/attach/detach/destroy aren't hot paths, what is? Those are > fork/exec/exit cgroup analogs. If you have thousands upon thousands of Things like page faults? cgroup controllers hook into subsystems and their hot path operations get affected by the method of cgroup association. Also, migration and create/destroy are completely different. create/destroy don't need much synchronization - a new task is made visible only after the initial association is set up and a dying task's association is destroyed only after the task isn't referenced by anybody. There's nothing dynamic about those compared to migration. > potentially active cgroups (aka customers), you wouldn't want to keep > them all around just in case when you can launch cgroup tasks the same > way we launch any other task. You wouldn't contemplate slowing down > fork/exec/exit, but create/attach/detach/destroy are one and the same.. > they need to be just as fast/light as they can be, as they are part and > parcel of the higher level process. You're conflating two completely different operations. Also, when I say migration is a relatively expensive operation, I'm comparing it to bouncing a request to another thread as opposed to bouncing the issuing thread to different cgroup request-by-request. > That's why my hack ended up in a large enterprise outfit's product, it > was _needed_ to fix up cgroups performance suckage. That suckage was > fixed up properly quite a bit later. Hmm... I bet you're talking about the removal of synchronize_rcu() in migration path, sure, that was a silly thing to have there but also that comparison is likely a couple orders of magnitude off of what the thread was originally talking about. > Anyway, if what they or anybody like them can currently do with their > job launcher/manager gizmos is negatively impacted, they can gripe for > themselves. All I'm saying is that there are definitely users out there > to whom create/attach/detach/destroy are highly important. Hmmm... I think this discussion got pretty badly derailed at this point. If I'm not mistaken, you're talking about tens or a few hundred millisecs of latency per migration which no longer exists and won't ever come back and the discussion originally was about something like migrating thread for issuing several IO requests versus bouncing that to a dedicated issuer thread in that domain. 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
