On 2017-11-16 16:45, Peter Zijlstra wrote:
On Wed, Nov 15, 2017 at 11:03:08PM +0100, Thomas Gleixner wrote:
If I understand the problem correctly then he wants to avoid the heavy
lifting in tick_nohz_idle_enter() in the first place, but there is already
an interesting quirk there which makes it exit early.
Sure. And there are people who want to do the same for native.
Adding more ugly and special cases just isn't the way to go about doing
that.
I'm fairly sure I've told the various groups that want to tinker with
this to work together on this. I've also in fairly significant detail
sketched how to rework the idle code and idle predictors.
At this point I'm too tired to dig any of that up, so I'll just keep
saying no to patches that don't even attempt to go in the right
direction.
Peter, take care.
I really have considered this factor, and try my best not to interfere
with scheduler/idle code.
if irq_timings code is ready, I can use it directly. I think irq_timings
is not an easy task, I'd
like to help as much as I can. Also don't try to touch tick_nohz* code
again.
as tglx suggested, this can be handled either in a HV specific idle driver or even in the generic core code.
I hope this is in the right direction.
Quan
Alibaba Cloud
