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

Re: [Xen-devel] [PATCH v2] new config option vtsc_khz_tolerance to avoid TSC emulation



>>> On 05.03.18 at 15:18, <olaf@xxxxxxxxx> wrote:
> Am Mon, 05 Mar 2018 06:18:17 -0700
> schrieb "Jan Beulich" <JBeulich@xxxxxxxx>:
> 
>> >>> On 05.03.18 at 12:35, <olaf@xxxxxxxxx> wrote:  
>> > +    case XEN_DOMCTL_set_vtsc_khz_tolerance:
>> > +        if ( d == currd )
>> > +            ret = -EINVAL;  
>> Why? There's e.g. no domain_pause() involved here.
> 
> I have thought about that. Now I think that part can be even simpler,
> just like the following XEN_DOMCTL_suppress_spurious_page_faults:
> just change that read-only value unconditionally. There is no obvious
> harm in changing that value.
> 
>> Also throughout the patch I wonder if it wasn't more natural to
>> put the unit last in the parameter / field names.
> 
> That was just to keep the diff slightly smaller.

I'm only talking about additions you make, and I don't see a size
difference between "vtsc_khz_tolerance" and "vtsc_tolerance_khz".

>> > +            printk(XENLOG_WARNING "%s: d%u: host has %lu kHz,"
>> > +                   " domU expects %u kHz,"
>> > +                   " difference of %u is %s tolerance of %u\n",
>> > +                   __func__, d->domain_id, cpu_khz, gtsc_khz, khz_diff,
>> > +                   diff_tolerated ? "within" : "outside", 
>> > vtsc_khz_tolerance);  
>> Leftover debugging message?
> 
> I think it is worth to log that event, perhaps not with WARNING level.

XENLOG_G_INFO at most, I would say, and perhaps only when
the setting is non-zero.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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