On Tue, 15 Jul 2014, Peter Zijlstra wrote: > On Tue, Jul 15, 2014 at 11:50:45AM +0200, Peter Zijlstra wrote: > > So you already have an idle notifier (which is x86 only, we should fix > > that I suppose), and you then double check there really isn't anything > > else running. > > Note that we've already done a large part of the expense of going idle > by the time we call that idle notifier -- in specific, we've > reprogrammed the clock to stop the tick. > > Its really wasteful to then generate work again, which means we have to > again reprogram the clock etc. Doing anything which is not related to idle itself in the idle notifier is just plain wrong. If that stuff wants to utilize idle slots, we really need to come up with a generic and general solution. Otherwise we'll grow those warts all over the architecture space, with slightly different ways of wreckaging the world an some more. This whole attidute of people thinking that they need their own specialized scheduling around the real scheduler is a PITA. All this stuff is just damanging any sensible approach of power saving, load balancing, etc. What we really want is infrastructure, which allows the scheduler to actively query the async work situation and based on the results actively decide when to process it and where. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
