On Wed, 2015-09-02 at 12:16 -0400, Chris Metcalf wrote: > On 09/02/2015 05:38 AM, Mike Galbraith wrote: > > IMHO, nohz_full -> cpu_isolated_map removal really wants to happen. > > NO_HZ_FULL_ALL currently means "Woohoo, next stop NR_CPUS=0". > > Yeah, the problem seems to be folks who use it as a kind of > "hey, maybe this gives me some optimization boost somewhere" > kind of setting. Did we ever hear actual use cases for people who > benefited from running nohz_full on cpus with an active scheduler, > i.e. no isolcpus for that core? I find it hard to imagine, but, maybe...?
The only sane usage atm is my entire box (small, big likely won't boot) is a dedicated specialist. Previously, you could also have had the feature is valuable enough that I'm willing to pay the quite high price to have this feature available for whenever I feel like using it. > If we don't have such use cases, what should we do here? I'm > slightly sympathetic to these folks who are going "Gee, my machine > suddenly got way slower", but only in the same sense as people > who shoot themselves in the foot and then say "Gee, my foot is > bleeding". But maybe I'm being too hard core :-) I think it's bloody stupid to declare nohz_full cpus dead when they can in fact do generic work. There's no reason to do so... unless maybe we really do need to hold the hand of poor ole Aunt Tilly... the hapless HPC administrator who can't figure out how to use cpusets or such. When the overhead goes away, dynamic usage will become a lot more _practical_, but you can do it in the here and now modulo the cost and that bogus death certificate. They ain't dead, two patches combined to bury the poor things alive. -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/