On Wed, May 22, 2019 at 05:44:34PM +0200, Paolo Bonzini wrote: > On 22/05/19 17:04, Marcelo Tosatti wrote: > > Consider sequence of wakeup events as follows: > > 20us, 200us, 20us, 200us... > > I agree it can happen, which is why the grow/shrink behavior can be > disabled for halt_poll_ns. Is there a real-world usecase with a > sequence like this? If you have a database with variable response times in the 20,200,20,200... range, then yes. Its not a bizzarre/unlikely sequence. You didnt answer my question at the end of the email. > The main qualm I have with guest-side polling is that it encourages the > guest admin to be "impolite". But I guess it was possible even now to > boot guests with idle=poll, which would be way more impolite... Yep. Thanks. > Paolo > > > If one enables guest halt polling in the first place, > > then the energy/performance tradeoff is bend towards > > performance, and such misses are harmful. > > > > So going to add something along the lines of: > > > > "If, after 50 consecutive times, block_time is much larger than > > halt_poll_ns, then set cpu->halt_poll_ns to zero". > > > > Restore user halt_poll_ns value once one smaller block_time > > is observed. > > > > This should cover the full idle case, and cause minimal > > harm to performance. > > > > Is that OK or is there any other characteristic of > > adaptive halt poll you are looking for?
