Hello, Mike. On Wed, Aug 19, 2015 at 05:23:40AM +0200, Mike Galbraith wrote: > Hm. I know of a big data outfit to which attach/detach performance was > important enough for them to have plucked an old experimental overhead > reduction hack (mine) off lkml, and shipped it. It must have mattered a > LOT for them (not suicidal crash test dummies) to have done that. There haven't been any guidelines on cgroup usage. Of course people have been developing in all directions. It's a natural learning process and there are use cases which can be served by migrating processes back and forth. Nobody is trying to prevent that; however, if one examines how resources and their associations need to be tracked for accounting and control, it's evident that there are inherent trade-offs between migration and the stuff which happens while not migrating and it's clear which side is more important. 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. 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
