> Still, I think we have dynamic polling to mitigate this overhead;
> how was it behaving?
Correctly: the polling stopped as soon as the benchmark ended. :)
> I noticed a questionable decision in growing the window:
> we know how long the polling should have been (block_ns), but we do not
> use
2017-05-16 18:58+0200, Paolo Bonzini:
> On 18/04/2017 12:41, Paolo Bonzini wrote:
>> In some fio benchmarks, halt_poll_ns=40 caused CPU utilization to
>> increase heavily even in cases where the performance improvement was
>> small. In particular, bandwidth divided by CPU usage was as much as
On 18/04/2017 12:41, Paolo Bonzini wrote:
> In some fio benchmarks, halt_poll_ns=40 caused CPU utilization to
> increase heavily even in cases where the performance improvement was
> small. In particular, bandwidth divided by CPU usage was as much as
> 60% lower.
>
> To some extent this is
In some fio benchmarks, halt_poll_ns=40 caused CPU utilization to
increase heavily even in cases where the performance improvement was
small. In particular, bandwidth divided by CPU usage was as much as
60% lower.
To some extent this is the expected effect of the patch, and the
additional CPU
4 matches
Mail list logo