2013/2/7 Steven Rostedt <[email protected]>: > On Thu, 2013-02-07 at 17:41 +0100, Frederic Weisbecker wrote: > >> I'm not convinced that "single task" must be a fundamental component >> of this. It's an implementation detail. We should be able to keep the >> tick off in the future when more than one task are on the runqueue and >> hrtick is on. May be this will never show up as a performance gain but >> we don't know yet. >> >> Ok let's talk about that single task constraint in the Kconfig help so >> that the user knows the practical constraint as of today. But I >> suggest we keep that as an internal detail that we can deal with in >> the future. > > Hmm, but isn't time slices still implemented by ticks?
Not with hrtick. > I would think > implementing multiple tasks would be another huge change. I don't think so. Really hrtick should take of everything. > > Maybe have: > > NO_HZ_IDLE > NO_HZ_SINGLE_TASK > NO_HZ_MULTI_TASK > NO_HZ_COMPLETE I still see single task, multitask or complete as implementation constraints. Once we make hrtick support dynticks, it should be dynamically handled: if hrtick is enabled then stop the tick even on multitask, otherwise only stop it when we have one task. Then when we remove jiffies, the complete coverage comes along. > > And as Ingo has suggested, maybe in the future we can remove SINGLE and > MULTI and have just COMPLETE. But really, turning these constraints into single built-in optable choices doesn't make much sense to me. > But anyway, the current method has a strict requirement of a single > task, and that is user visible. I would want to keep the config name > implying that requirement. As long as it's specified in the Kconfig help, does it matter? It''s a constraint amongst many others: you need to keep one CPU with a periodic tick, you need to avoid posix cpu timers, etc... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
