On Thu, Aug 29, 2019 at 09:53:04AM -0300, Marcelo Tosatti wrote: > On Thu, Aug 29, 2019 at 08:16:41PM +0800, Wanpeng Li wrote: > > > Current situation regarding haltpoll driver is: > > > > > > overcommit group: haltpoll driver is not loaded by default, they are > > > happy. > > > > > > non overcommit group: boots without "realtime hints" flag, loads haltpoll driver, > > > happy. > > > > > > Situation with patch above: > > > > > > overcommit group: haltpoll driver is not loaded by default, they are > > > happy. > > > > > > non overcommit group: boots without "realtime hints" flag, haltpoll driver > > > cannot be loaded. > > > > non overcommit group, if they don't care latency/performance, they > > don't need to enable haltpoll, "realtime hints" etc. Otherwise, they > > should better tune. > > As mentioned before, "being overcommitted" is a property which is transitional. > > A static true/false scheme reflects this poorly. > > Therefore the OS should detect it and act accordingly. Hi Wanpeng Li, One suggestion for a dynamic "is overcommited" scheme: If the amount of stolen time, in the past record_steal_time window, is more than 20% of the time in that window, then mark system as overcommitted. Otherwise, clear it. Make that 20% configurable by as kvm module parameter. Use that info to enable/disable overcommit features. That should work, right?
