Re: [Xen-devel] [PATCH] perfc: Print a system time in a convenient format

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 11.09.18 at 11:28, <george.dunlap@xxxxxxxxxx> wrote:
> On 09/11/2018 10:18 AM, Jan Beulich wrote:
>>>>> On 11.09.18 at 11:15, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 11/09/18 10:10, Jan Beulich wrote:
>>>>>>> On 11.09.18 at 10:50, <andrii_anisov@xxxxxxxx> wrote:
>>>>> On 11.09.18 11:27, Jan Beulich wrote:
>>>>>> NAK, for two reasons: I'm not of the opinion that reading a 15 or more
>>>>>> digit decimal number without any separators is any easier than the
>>>>>> current format.
>>>>> It's quite subjective. IMHO timestamps measured in ns easier to 
>>>>> understand in decimals rather than in separated 32-bit hex-es. No matter 
>>>>> how many digital number they have.
>>>> It is subjective, yes, but in such a case you even more so need to
>>>> demonstrate a change is an overall improvement.
>>>>
>>>>> Even post processing of perfc output is easier in case of decimal 
>>>>> timestamps. You should not parse hexes and odd separators to calculate 
>>>>> the time elapsed between two samples.
>>>> Post processing usually uses scrips for parsing - I don't think it's
>>>> overly complicated to have a script convert the number into
>>>> basically any format you want.
>>>
>>> Right, but this particular mis-pattern wants fixing.  It is simply
>>> confusing to have a single number formatted with a colon inbetween.
>> 
>> What other separator do you suggest? I consider it quite helpful
>> to have one when there are more than about 10 digits. (I'd also
>> be fine, btw, to have the time printed in decimal, but then
>> perhaps with ms granularity and 6 digits for the fractional part.)
> 
> * We clearly already have a standard way of printing stime
> * The places where a colon is used are non-standard, and thus wrong
> * His patch makes an improvement by fixing the non-standard timestamp
> printing.
> 
> If you're not happy with the current PRI_stime, then it should be on you
> to propose and code up a change, not Andrii (unless he feels
> particularly motivated to do so).

Excuse me, but no. I'm sure there are places where PRI_stime is
fine to use as is, or there are people thinking so. But to me
personally the proposed change is the opposite of an improvement,
and hence I think I'm perfectly fine to object without going and
creating a counter proposal patch myself. If I'm the only one, I
can still be talked into accepting the change, or outvoted.

Jan



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