search for: irq_tim

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

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

...> looks similar. But lets not proliferate that. I'd rather see that go >> away. > > agreed. > > Even we can get more benifit than commit 3c5d92a0cfb5 ("nohz: Introduce > arch_needs_cpu") > in kvm guest. I won't proliferate that.. > >> But the irq_timings stuff is heading into the same direction, with a more >> complex prediction logic which should tell you pretty good how long that >> idle period is going to be and in case of an interrupt heavy workload >> this >> would skip the extra work of stopping and restarting the...

...> looks similar. But lets not proliferate that. I'd rather see that go >> away. > > agreed. > > Even we can get more benifit than commit 3c5d92a0cfb5 ("nohz: Introduce > arch_needs_cpu") > in kvm guest. I won't proliferate that.. > >> But the irq_timings stuff is heading into the same direction, with a more >> complex prediction logic which should tell you pretty good how long that >> idle period is going to be and in case of an interrupt heavy workload >> this >> would skip the extra work of stopping and restarting the...

..._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 stuff is heading into the same direction, with a more complex prediction logic which should tell you pretty good how long that idle period is going to be and in case of an interrupt heavy workload this would skip the extra work of stopping and restarting the tick and provide a very good input i...

..._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 stuff is heading into the same direction, with a more complex prediction logic which should tell you pretty good how long that idle period is going to be and in case of an interrupt heavy workload this would skip the extra work of stopping and restarting the tick and provide a very good input i...

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

...lets not proliferate that. I'd rather see that go >>> away. >> agreed. >> >> Even we can get more benifit than commit 3c5d92a0cfb5 ("nohz: Introduce >> arch_needs_cpu") >> in kvm guest. I won't proliferate that.. >> >>> But the irq_timings stuff is heading into the same direction, with a more >>> complex prediction logic which should tell you pretty good how long that >>> idle period is going to be and in case of an interrupt heavy workload >>> this >>> would skip the extra work of stopping and...

...h_needs_cpu"). The reason for this commit > looks similar. But lets not proliferate that. I'd rather see that go away. agreed. Even we can get more benifit than commit 3c5d92a0cfb5 ("nohz: Introduce arch_needs_cpu") in kvm guest. I won't proliferate that.. > But the irq_timings stuff is heading into the same direction, with a more > complex prediction logic which should tell you pretty good how long that > idle period is going to be and in case of an interrupt heavy workload this > would skip the extra work of stopping and restarting the tick and provide a &g...

From: Yang Zhang <yang.zhang.wz at gmail.com> Implement a generic idle poll which resembles the functionality found in arch/. Provide weak arch_cpu_idle_poll function which can be overridden by the architecture code if needed. Interrupts arrive which may not cause a reschedule in idle loops. In KVM guest, this costs several VM-exit/VM-entry cycles, VM-entry for interrupts and VM-exit

...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, which seems not working so far. V1 -> V2: - integrate the smart halt poll into paravirt code - use idle_stamp instead of check_poll - since it hard to get whether vcpu is the only task in pcpu, so we don't consider it in this series.(May improve it in future) --- Quan X...

...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, which seems not working so far. V1 -> V2: - integrate the smart halt poll into paravirt code - use idle_stamp instead of check_poll - since it hard to get whether vcpu is the only task in pcpu, so we don't consider it in this series.(May improve it in future) --- Quan X...

...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, which seems not working so far. V1 -> V2: - integrate the smart halt poll into paravirt code - use idle_stamp instead of check_poll - since it hard to get whether vcpu is the only task in pcpu, so we don't consider it in this series.(May improve it in future) --- Quan X...

...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, which seems not working so far. V1 -> V2: - integrate the smart halt poll into paravirt code - use idle_stamp instead of check_poll - since it hard to get whether vcpu is the only task in pcpu, so we don't consider it in this series.(May improve it in future) --- Quan X...

...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, which seems not working so far. V1 -> V2: - integrate the smart halt poll into paravirt code - use idle_stamp instead of check_poll - since it hard to get whether vcpu is the only task in pcpu, so we don't consider it in this series.(May improve it in future) --- Quan X...

...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, which seems not working so far. V1 -> V2: - integrate the smart halt poll into paravirt code - use idle_stamp instead of check_poll - since it hard to get whether vcpu is the only task in pcpu, so we don't consider it in this series.(May improve it in future) --- Quan X...