[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/2] x86/HVM: Use fixed TSC value when saving or restoring domain

>>> On 31.03.14 at 17:06, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 03/31/2014 10:34 AM, Jan Beulich wrote:
>>>>> index 95b4b91..032eb23 100644
>>>>> --- a/xen/include/xen/time.h
>>>>> +++ b/xen/include/xen/time.h
>>>>> @@ -32,7 +32,8 @@ struct vcpu;
>>>>>    typedef s64 s_time_t;
>>>>>    #define PRI_stime PRId64
>>>>> -s_time_t get_s_time(void);
>>>>> +s_time_t get_s_time_fixed(u64 at_tick);
>>>>> +#define get_s_time() get_s_time_fixed(0)
>>>> get_s_time(), through NOW(), has quite many users, so I'm not certain
>>>> the code bloat resulting from this is desirable. I'd suggest the function
>>>> to remain such; the compiler will be able to make it a mov+jmp.
>>> Sorry, not sure I understand what you are asking for.
>>> There shouldn't be much of code size increase since get_s_time()
>>> currently (and get_s_time_fixed() after this patch is applied) are not
>>> inlines. The only increase is due to routine itself getting very
>>> slightly larger.
>>> But I suspect you meant something else.
>> All call sites have to zero %edi with the change in place, and I
>> was trying to tell you that the number of call sites of this isn't
>> exactly small due to the function's use via NOW(). Hence I think
>> you shouldn't penalize the callers and have an explicit out of line
>> wrapper.
> OK, I understand the concern now but still confused about what you want ;-(
> Two separate routines that only differ in how tsc is calculated (rdtscll 
> vs. an 'in' parameter)?

No - I'm fine with get_s_time() being a wrapper for get_s_time_fixed(),
just that I ask it to be a proper out-of-line function rather than an
inline one or a macro.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.