Re: API change request. Was => Re: Time accounting on statclock()

[Cherry G.Mathew <cherry%zyx.in@localhost>]

Jason Thorpe <thorpej%me.com@localhost> writes:

>> On Nov 18, 2018, at 11:00 AM, Martin Husemann <martin%duskware.de@localhost> wrote:
>> 
>> On Sun, Nov 18, 2018 at 04:19:50PM +0530, Cherry G.Mathew wrote:
>>> Typo:
>>> https://mail-index.netbsd.org/source-changes/2018/11/18/msg100702.html
>> 
>> Ugh - can't you just modify
>> 
>> CLKF_USERMODE(frame)
>> CLKF_PC(frame)
>> CLKF_INTR(frame)
>> 
>> for xen making them ignore their frame argument and use the per-cpu cached
>> (but more minimal) data instead?
>
> +1
>
> In addition to "we shouldn't even have this hardclock() interrupt
> anyway", it also makes the signature of hardclock() "not like a
> regular interrupt handler".
>

If you mean the timing signature, Specifically in the case of xen, the
clock interrupt is really randomly skewed (depending on the hypervisor
scheduler algorithm, load, etc.). We even have a nice little bug where
time runs backwards on the domains because our compensatory algorithms
aren't able to do it perfectly. From that PoV, there's no timing
signature impact.

I'll work on reducing the memory copying overhead though.

-- 
~cherry