Re: calcru: runtime went backwards

In message <20060212220216.F1605_at_free.home.local>, Yuriy Tsibizov writes:
>On Sun, 12 Feb 2006, Poul-Henning Kamp wrote:
>> In message <20060212114050.I1160_at_free.home.local>, Yuriy Tsibizov writes:
>>> while playing 8 PCM streams in parallel (it uses almost all CPU power I
>>> have).
>>>
>>> -CURRENT with last changes to src/sys from imp at 2006-02-11 03:58:07 UTC
>>
>> Can you try to update to a more recent current ?  I think you have
>> not gotten my latest commit to the cpu time accounting at that
>> point...
>With -CURRENT up to 2006-02-12 06:57:41 UTC (last commit by scottl)
>I still can see some calcru messages:

Right, but these have much smaller deltas than the other ones you saw.

>calcru: runtime went backwards from 3508844 usec to 3508842 usec for pid 28 (pagezero)

My theory currently is that these are side effects of the cputick
calibration code:  If the cputick rate gets measured to be a bit higher,
the next calculation will result in slightly lower numbers for the
cpu utilization in microseconds and the warning will fire.

This will be particularly easy to trigger on machines with power
management on (laptops mostly).

My current inclination is to simply not issue this warning if the
cpu_tick is marked as "variable".

The other side of this is that I've been looking at having the
ACPI power management code announce the maximum speed of the TSC
to the cputick code, that would make such machines "fixed frequency"
cpu_tick machines from the start and even if enabled, this warning
should not issue in that case.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.