Re: [RFC PATCH v2 0/7] x86/idle: add halt poll support

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Aug 29, 2017 at 10:02:15PM +0800, Wanpeng Li wrote:
> > Here is the data we get when running benchmark netperf:
> >
> >    2. w/ patch:
> >       halt_poll_threshold=10000 -- 15803.89 bits/s -- 159.5 %CPU
> >       halt_poll_threshold=20000 -- 15899.04 bits/s -- 161.5 %CPU
> >       halt_poll_threshold=30000 -- 15642.38 bits/s -- 161.8 %CPU
> >       halt_poll_threshold=40000 -- 18040.76 bits/s -- 184.0 %CPU
> >       halt_poll_threshold=50000 -- 18877.61 bits/s -- 197.3 %CPU
> >
> >    3. kvm dynamic poll
> >       halt_poll_ns=10000 -- 15876.00 bits/s -- 172.2 %CPU
> >       halt_poll_ns=20000 -- 15602.58 bits/s -- 185.4 %CPU
> >       halt_poll_ns=30000 -- 15930.69 bits/s -- 194.4 %CPU
> >       halt_poll_ns=40000 -- 16413.09 bits/s -- 195.3 %CPU
> >       halt_poll_ns=50000 -- 16417.42 bits/s -- 196.3 %CPU
> >
> 
> Actually I'm not sure how much sense it makes to introduce this pv
> stuff and the duplicate adaptive halt-polling logic as what has
> already been done in kvm w/o obvious benefit for real workload like
> netperf. In addition, as you mentioned offline to me, enable both the

"real workload like netperf"? 

That is not a real workload. That is a synthetic one.

> patchset and the adaptive halt-polling logic in kvm simultaneously can
> result in more cpu power consumption. I remembered that David from
> Google mentioned that Windows Event Objects can get 2x latency
> improvement in KVM FORUM, which means that the adaptive halt-polling
> in kvm should be enabled by default. So if the windows guests and
> linux guests are mixed on the same host, then this patchset will
> result in more cpu power consumption if the customer enable the
> polling in the linux guest. Anyway, if the patchset is finally

More CPU power consumption sounds as a bad idea, does it not?

> acceptable by maintainer, I will introduce the generic adaptive
> halt-polling framework in kvm to avoid the duplicate logic.
> 
> Regards,
> Wanpeng Li