On 05/18/2016 12:10 PM, Dario Faggioli wrote: > On Wed, 2016-05-18 at 16:53 +0200, Juergen Gross wrote: >> On 18/05/16 16:46, Boris Ostrovsky wrote: >>> >>> Won't we be accounting for stolen cycles twice now --- once from >>> steal_account_process_tick()->steal_clock() and second time from >>> do_stolen_accounting()? >> Uuh, yes. >> >> I guess I should rip do_stolen_accounting() out, too? It is a >> Xen-specific hack, so I guess nobody will cry. Maybe it would be a >> good idea to select CONFIG_PARAVIRT_TIME_ACCOUNTING for XEN then? >> > So, config options aside, if I understand this correctly, it looks like > we were actually already doing steal time accounting, although in a > non-standard way. > > And yet, people seem to have issues relating to lack of (proper?) steal > time accounting (Cc-ing Tony). > > I guess this means that, either: > - the issue being reported is actually not caused by the lack of > steal time accounting, > - our current (Xen specific) steal time accounting solution is flawed, > - the issue is caused by the lack of the bit of steal time accounting > that we do not support yet,
I believe it's this one. Tony narrowed the problem down to update_curr() where vruntime is calculated, based on runqueue's clock_task value. That value is computed in update_rq_clock_task(), which needs paravirt_steal_rq_enabled. -boris > - other ideas? Tony? > > Dario