Quan Xu
2017-Nov-16 09:29 UTC
[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
Thomas Gleixner
2017-Nov-16 09:47 UTC
[PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path
On Thu, 16 Nov 2017, Quan Xu wrote:> On 2017-11-16 16:45, Peter Zijlstra wrote: > > 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.It's not a question whether irq_timings code is ready or not. The infrastructure is there. I said that before and I'm happy to repeat: All parties who need this kind of prediction should: 1) Talk to each other 2) Work together to make it usable for _ALL_ use cases AFAICT, that never happened. Otherwise there would be either progress on that or at least a reasonable explanation WHY it cannot be done. Peter and myself made it entirely clear several times in the past that this must be solved at the generic level without any magic hackery in random places. But the only thing we've seen so far is the magic hackery coming around in a different flavour some time after we rejected the last one. We can play that game forever. The outcome is extremly predictable. Thanks, tglx
Reasonably Related Threads
- [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path
- [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path
- [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path
- [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path
- [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path