On Wed, Jan 20, 2016 at 09:42:16AM +0100, Thomas Gleixner wrote: > > The above changelog is just crap and doesnt make any sense at all. And the > patch is fixing symptoms not the root cause.
IMHO, the root cause is the "tick" definition. Am I only one confused? I am confused now. What is tick? The timer interrupt for handling rcu callback or irq work while the (perioid) tick was stoped, is a tick? If it is true, then many code including scheduler assuming tick happens periodically must be fixed to be able to handle the non-periodic tick, esp. scheduler_tick(). And we have to focus that. Then we don't need something accounting a cpu load remotely and periodically, because the local tick handler can account it well locally. If it is not true, that is, the timer interrupt for handling rcu callback or irq work during tick-stopped, is not a tick but just a interrupt by which we want something to be done, then I think we need to make the handler do only its purpose. In this case, tick related handling has to be deferred to the tick-restart point. And we have to focus it, so that it can be done. Regardless of the answer, true or not true, if there is something the housekeeper must do periodically, then it should be done even remotely. But I think accounting cpu load is not the case. The way to implement it depends on the above answer. IMHO, the letter direction is better. Just a my opinion, and I maybe lack kernel knowledge compared with you. Please let me know if I am wrong. Or please let me know your opinions. > > Thanks, > > tglx >
