search for: tick_nohz_idle_enter

From: Quan Xu <quan.xu0 at gmail.com> the last idle loop is from tick_nohz_idle_enter to tick_nohz_idle_exit. Signed-off-by: Yang Zhang <yang.zhang.wz at gmail.com> Signed-off-by: Quan Xu <quan.xu0 at gmail.com> Cc: Frederic Weisbecker <fweisbec at gmail.com> Cc: Thomas Gleixner <tglx at linutronix.de> Cc: Ingo Molnar <mingo at kernel.org> Cc: linux-ke...

From: Quan Xu <quan.xu0 at gmail.com> the last idle loop is from tick_nohz_idle_enter to tick_nohz_idle_exit. Signed-off-by: Yang Zhang <yang.zhang.wz at gmail.com> Signed-off-by: Quan Xu <quan.xu0 at gmail.com> Cc: Frederic Weisbecker <fweisbec at gmail.com> Cc: Thomas Gleixner <tglx at linutronix.de> Cc: Ingo Molnar <mingo at kernel.org> Cc: linux-ke...

...pensive than bare metal. Add a generic idle poll before enter > > real idle path. When a reschedule event is pending, we can bypass > > the real idle path. > > Why not do a HV specific idle driver? 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. See commit 3c5d92a0cfb5 ("nohz: Introduce arch_needs_cpu"). The reason for this commit looks similar. But lets not proliferate that. I'd rather see that go away. But the irq_timings stuf...

...pensive than bare metal. Add a generic idle poll before enter > > real idle path. When a reschedule event is pending, we can bypass > > the real idle path. > > Why not do a HV specific idle driver? 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. See commit 3c5d92a0cfb5 ("nohz: Introduce arch_needs_cpu"). The reason for this commit looks similar. But lets not proliferate that. I'd rather see that go away. But the irq_timings stuf...

...[<ffffffff810e4745>] tick_nohz_idle_exit+0x195/0x1b0 [<ffffffff810da755>] cpu_startup_entry+0x205/0x250 [<ffffffff81661070>] cpu_bringup_and_idle+0x13/0x15 ---[ end trace 915c8c486004dda1 ]--- b/c ts_inidle is set to zero. Thomas suggested that we just add a workaround to call tick_nohz_idle_enter before returning from xen_play_dead() - and that is what this patch does and fixes the issue. We also add the stable part b/c git commit 4b0c0f294 is on the stable tree. CC: stable@vger.kernel.org Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Konrad Rzeszutek Wilk <ko...

...*/ +void __weak arch_cpu_idle_poll(void) { } void __weak arch_cpu_idle_prepare(void) { } void __weak arch_cpu_idle_enter(void) { } void __weak arch_cpu_idle_exit(void) { } @@ -219,6 +220,7 @@ static void do_idle(void) */ __current_set_polling(); + arch_cpu_idle_poll(); quiet_vmstat(); tick_nohz_idle_enter(); -- 1.7.1

...ffff810c29ea>] handle_fasteoi_irq+0x5a/0x100 [ 16.615272] [<ffffffff81015cde>] handle_irq+0x1e/0x30 [ 16.615276] [<ffffffff8172c6cd>] do_IRQ+0x4d/0xc0 [ 16.615281] [<ffffffff81721e6d>] common_interrupt+0x6d/0x6d [ 16.615283] <EOI> [<ffffffff810d63c1>] ? tick_nohz_idle_enter+0x41/0x70 [ 16.615289] [<ffffffff810d63bd>] ? tick_nohz_idle_enter+0x3d/0x70 [ 16.615292] [<ffffffff810beb48>] cpu_startup_entry+0x88/0x290 [ 16.615297] [<ffffffff81707e97>] rest_init+0x77/0x80 [ 16.615302] [<ffffffff81d35f70>] start_kernel+0x438/0x443 [ 16.615...

...neric idle poll before enter >>>> real idle path. When a reschedule event is pending, we can bypass >>>> the real idle path. >>> Why not do a HV specific idle driver? >> 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.? See commit >> 3c5d92a0cfb5 ("nohz: Introduce arch_needs_cpu"). The reason for this >> commit >> looks similar. But lets not proliferate that. I'd rathe...

...neric idle poll before enter >>>> real idle path. When a reschedule event is pending, we can bypass >>>> the real idle path. >>> Why not do a HV specific idle driver? >> 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.? See commit >> 3c5d92a0cfb5 ("nohz: Introduce arch_needs_cpu"). The reason for this >> commit >> looks similar. But lets not proliferate that. I'd rathe...

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 gr...

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 sur...

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 sur...

...re enter >>>>> real idle path. When a reschedule event is pending, we can bypass >>>>> the real idle path. >>>> Why not do a HV specific idle driver? >>> 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.? See commit >>> 3c5d92a0cfb5 ("nohz: Introduce arch_needs_cpu"). The reason for this >>> commit >>> looks similar. But lets not proliferate...

...-- 42225.3 bit/s -- 198.7 %CPU halt_poll_ns=30000 & halt_poll_threshold=30000 -- 42210.7 bit/s -- 200.3 %CPU 5. idle=poll 37081.7 bit/s -- 998.1 %CPU --- V2 -> V3: - move poll update into arch/. in v3, poll update is based on duration of the last idle loop which is from tick_nohz_idle_enter to tick_nohz_idle_exit, and try our best not to interfere with scheduler/idle code. (This seems not to follow Peter's v2 comment, however we had a f2f discussion about it in Prague.) - enhance patch desciption. - enhance Documentation and sysctls. - test with IRQ_TIMINGS related code, whi...

...-- 42225.3 bit/s -- 198.7 %CPU halt_poll_ns=30000 & halt_poll_threshold=30000 -- 42210.7 bit/s -- 200.3 %CPU 5. idle=poll 37081.7 bit/s -- 998.1 %CPU --- V2 -> V3: - move poll update into arch/. in v3, poll update is based on duration of the last idle loop which is from tick_nohz_idle_enter to tick_nohz_idle_exit, and try our best not to interfere with scheduler/idle code. (This seems not to follow Peter's v2 comment, however we had a f2f discussion about it in Prague.) - enhance patch desciption. - enhance Documentation and sysctls. - test with IRQ_TIMINGS related code, whi...

...-- 42225.3 bit/s -- 198.7 %CPU halt_poll_ns=30000 & halt_poll_threshold=30000 -- 42210.7 bit/s -- 200.3 %CPU 5. idle=poll 37081.7 bit/s -- 998.1 %CPU --- V2 -> V3: - move poll update into arch/. in v3, poll update is based on duration of the last idle loop which is from tick_nohz_idle_enter to tick_nohz_idle_exit, and try our best not to interfere with scheduler/idle code. (This seems not to follow Peter's v2 comment, however we had a f2f discussion about it in Prague.) - enhance patch desciption. - enhance Documentation and sysctls. - test with IRQ_TIMINGS related code, whi...

...-- 42225.3 bit/s -- 198.7 %CPU halt_poll_ns=30000 & halt_poll_threshold=30000 -- 42210.7 bit/s -- 200.3 %CPU 5. idle=poll 37081.7 bit/s -- 998.1 %CPU --- V2 -> V3: - move poll update into arch/. in v3, poll update is based on duration of the last idle loop which is from tick_nohz_idle_enter to tick_nohz_idle_exit, and try our best not to interfere with scheduler/idle code. (This seems not to follow Peter's v2 comment, however we had a f2f discussion about it in Prague.) - enhance patch desciption. - enhance Documentation and sysctls. - test with IRQ_TIMINGS related code, whi...

...bare metal. Add a generic idle poll before enter >>> real idle path. When a reschedule event is pending, we can bypass >>> the real idle path. >> Why not do a HV specific idle driver? > 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. See commit > 3c5d92a0cfb5 ("nohz: Introduce arch_needs_cpu"). The reason for this commit > looks similar. But lets not proliferate that. I'd rather see that go away. agreed....

...-- 42225.3 bit/s -- 198.7 %CPU halt_poll_ns=30000 & halt_poll_threshold=30000 -- 42210.7 bit/s -- 200.3 %CPU 5. idle=poll 37081.7 bit/s -- 998.1 %CPU --- V2 -> V3: - move poll update into arch/. in v3, poll update is based on duration of the last idle loop which is from tick_nohz_idle_enter to tick_nohz_idle_exit, and try our best not to interfere with scheduler/idle code. (This seems not to follow Peter's v2 comment, however we had a f2f discussion about it in Prague.) - enhance patch desciption. - enhance Documentation and sysctls. - test with IRQ_TIMINGS related code, whi...

...-- 42225.3 bit/s -- 198.7 %CPU halt_poll_ns=30000 & halt_poll_threshold=30000 -- 42210.7 bit/s -- 200.3 %CPU 5. idle=poll 37081.7 bit/s -- 998.1 %CPU --- V2 -> V3: - move poll update into arch/. in v3, poll update is based on duration of the last idle loop which is from tick_nohz_idle_enter to tick_nohz_idle_exit, and try our best not to interfere with scheduler/idle code. (This seems not to follow Peter's v2 comment, however we had a f2f discussion about it in Prague.) - enhance patch desciption. - enhance Documentation and sysctls. - test with IRQ_TIMINGS related code, whi...