2017-11-16 10:24:37

by Peter Zijlstra

[permalink] [raw]
Subject: Re: [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

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.

From 1584216194250926452@xxx Thu Nov 16 09:58:16 +0000 2017
X-GM-THRID: 1584141070007959176
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread


2017-11-16 09:52:54

by Quan Xu

[permalink] [raw]
Subject: Re: [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path



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


From 1584215588470805426@xxx Thu Nov 16 09:48:38 +0000 2017
X-GM-THRID: 1584141070007959176
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread