On Wed, Mar 23, 2005 at 09:33:07PM +0100, Christian Limpach wrote:
> > Yes.
> > The clock code isn't perfect. Especially, it doesn't compensate for the
> > fact that clock interrupts don't run at exacltly hz, because of domain
> > scheduling, and also because xen will send extra interrupts from
> > time to time, when domain0 updates the master clock. This needs more work.
> > Now, I'm not sure if this can cause the process time to become negative.
> > BTW, it this seems to happen only for kernel threads.
> 
> Yes, this has been a bug since day one and the time of some kernel threads
> seems to be wrong from the start.

Hum, this would be in MD code then ? Or some uninitialised variable in memory
it not zero'd out in xen ?

> 
> I thought Thor or I had added code to compensate for the irregular clock
> interrupts at some point?  It should keep the last time the clock was
> updated in a variable and then do no, one or several clock ticks at once
> depending on how many clock interrupts were lost.  With this code, it should
> then also be possible to set HZ to the same value as is used on NetBSD/i386.

Yes, this is there and is working. What is missing is the adjustements of
the cycle counter. cc_microset() is expected to be called at exactly hz,
it doesn't account for the drift resulting from domain scheduling,
nor for the fact that xen_timer_handler() can be called more often than
every clock tick.
We should probably reimplement cc_microset() locally, using the informations
provided by xen about the cycle counter.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--