lkml.org 
[lkml]   [2016]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] xen: add steal_clock support on x86
    From
    Date
    On 18/05/16 17:25, Boris Ostrovsky wrote:
    > On 05/18/2016 10:53 AM, Juergen Gross wrote:
    >> On 18/05/16 16:46, Boris Ostrovsky wrote:
    >>> On 05/18/2016 08:15 AM, Juergen Gross wrote:
    >>>> }
    >>>>
    >>>> +void __init xen_time_setup_guest(void)
    >>>> +{
    >>>> + pv_time_ops.steal_clock = xen_steal_clock;
    >>>> +
    >>>> + static_key_slow_inc(&paravirt_steal_enabled);
    >>>> + /*
    >>>> + * We can't set paravirt_steal_rq_enabled as this would require the
    >>>> + * capability to read another cpu's runstate info.
    >>>> + */
    >>>> +}
    >>> 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?
    >
    > I don't think PARAVIRT_TIME_ACCOUNTING is always selected for Xen. If

    This is easy to accomplish. :-)

    > that's indeed the case then we should ifndef do_stolen_accounting(). Or
    > maybe check for paravirt_steal_enabled.

    Is this really a sensible thing to do? There is a mechanism used by KVM
    to do the stolen accounting. I think we should use it instead of having
    a second implementation doing the same thing in case the generic one
    isn't enabled.

    Juergen

    \
     
     \ /
      Last update: 2016-05-18 18:01    [W:6.876 / U:1.844 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site