On Wed, 2013-09-11 at 14:21 +0000, Christoph Lameter wrote: > On Wed, 11 Sep 2013, Mike Galbraith wrote: > > > Mind saying why? To me, creating properties of exclusive sets of CPUs > > that the interface which manages sets and their properties is not fully > > aware of is a dainbramaged thing to do. > > cpusets is being replaced by cgropus. And the mechanism adds some > significant latencies to core memory management processing path.
You don't have to use or even configure in all controllers. > Also many folks in finance like to deal directly with the hardware > (processor numbers, affinity masks etc). There are already numerous ways > to specify these masks. Pretty well established. Digging down a cpuset > hierachy is a bit tedious. Then these cpusets can also overlap which > makes the whole setup difficult. These kind of things have to be exclusive set attributes 'course, overlapping nohz_tick/full/off just ain't gonna work very well. I hacked it up for my rt kernel to turn the tick on/off, and disable rt load balancing (cpupri adds jitter) on a per exclusive set basis. The cpuset bit is easy. Connecting buttons to scheduler and whatnot can make cute little "You'd better not EVER submit this" warts though :) > If cpusets can be used on top then ok but I would like it not to be > required to have that compiled in. IMHO, it makes much more sense to unify set attributes in cpusets, fixing up or griping about whatever annoys HPC boxen/folks. But whatever, I only piped in to mention that isolcpus wants to die, and I've done that, so I can pipe-down now. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
