On Wed, 2015-08-19 at 09:41 -0700, Tejun Heo wrote: > Most problems can be solved in different ways and I'm doubtful that > e.g. bouncing jobs to worker threads would be more expensive than > migrating the worker back and forth in a lot of cases. If migrating > threads around floats somebody's boat, that's fine but that has never > been and can't be the focus of design and optimization, not at the > cost of the actual hot paths. 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 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. 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. 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. -Mike -- 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
