From: "Gordon W. Ross" <gwr@mc.com>
Date: Wed, 20 Dec 95 12:31:48 EST
Message-Id: <9512201731.AA10046@bach>
To: Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU
Cc: netbsd-developers@NetBSD.ORG, cgd@BALVENIE.PDL.CS.CMU.EDU
In-Reply-To: <29373.819435881@BALVENIE.PDL.CS.CMU.EDU> (message from Chris G Demetriou on Wed, 20 Dec 1995 00:04:41 -0500)
Subject: Re: interface to put MD hooks into 'hardclock'?
Reply-To: "Gordon Ross" <gwr@mc.com>
Sender: owner-netbsd-developers@NetBSD.ORG
Precedence: first-class

> Cc: cgd@BALVENIE.PDL.CS.CMU.EDU
> X-Copyright: Copyright 1995, Christopher G. Demetriou.  All rights reserved.
> X-Notice: Duplication and redistribution prohibited without consent of
> 	  the author.
> Date: Wed, 20 Dec 1995 00:04:41 -0500
> From: Chris G Demetriou <Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU>
> Sender: owner-netbsd-developers@netbsd.org
> Precedence: first-class
> X-Loop: netbsd-developers@NetBSD.ORG
> 
> hi folks...
> 
> I'm wondering if anybody has any good ideas for ways to put
> machine-dependent hooks into hardclock()...

Why not just bounce through a port-specific function?
(The sun3 port uses clock_intr() that way.)

> In particular, what i need is something so that i can say:
> 
> Index: kern_clock.c
> ===================================================================
> RCS file: /usr/users/cgd/NetBSD/cvs/src/sys/kern/kern_clock.c,v
> retrieving revision 1.3
> diff -u -r1.3 kern_clock.c
> --- 1.3	1995/03/06 17:27:17
> +++ kern_clock.c	1995/12/20 02:25:50
> @@ -203,8 +203,10 @@
>  		if (tickfixcnt > tickfixinterval) {
>  			delta += tickfix;
>  			tickfixcnt = 0;
> +			reset_cc_offset();
>  		}
> -	}
> +	} else
> +		reset_cc_offset();
>  	if (timedelta != 0) {
>  		delta = tick + tickdelta;
>  		timedelta -= tickdelta;
> 
> that is, if tickfix == 0, then run that function every time a tick
> happens, otherwise run it when a tick causes tickfix to be applied...

This seems like a case where the granularity of the common code is
too large for effective sharing.  Perhaps hardclock chould be split
into a few separate functions, something like this for example:

    clock_callouts:   update the timeout queue
    clock_profile:    do process profiling stuff
    clock_ticktod:    increment TOD variables

The alpha would have its own version of clock_ticktod()
Then make hardclock() a port-specific function, i.e.:

hardclock(frame)
    register struct clockframe *frame;
{
    struct proc *p;
    clock_callouts();
    if ((p = curproc) != NULL)
        clock_profile(p);
    if (stathz == 0)
        statclock(frame);
    clock_ticktod();    /* custom version for alpha */
    if (needsoft) {        
        if (CLKF_BASEPRI(frame)) {
            /*
             * Save the overhead of a software interrupt;
             * it will happen as soon as we return, so do it now.
             */
            (void)splsoftclock();
            softclock();
        } else
            setsoftclock();
    }
}


> i've converted the Alpha to use the Process Cycle Counter when doing
> microtime(), and want to sync a cycle count 'base' with the clock
> every time the clock and the cycle counter should theoretically match.
> (that happens to be every time a tickfix is applied, if tickfix != 0,
> or at every clock tick.)
> 
> I'm also vaguely interested in adding something to hardclock so that
> it'll accumulate a clock tick into an interrupt counter, so that i
> don't have to jump through another function when going to hardclock...

Oh, you are concerned about an extra function call?
If so, that seems a little extreme to me.  How long does
one function call and return take on an alpha anyway?

> any ideas on how to do this reasonably?  I'd rather not #ifdef alpha,

Everyone has their own idea of "reasonable" 8^)

> because at least some of these hooks could potentially be useful on
> other ports.  (the pmax has a TC cycle counter that can be used for
> timing, apparently, and pentiums have cycle counters ... i dunno about
> anything else.)
> 
> it's nice to get ~10us resolution in userland via gettimeofday()... 8-)

Interesting.  Nice for timing code sections.  We do that in the
Mercury real-time OS (the one I work on in the daytime) by just
letting user processes have read access to the hi-res counters.
We get microsecond resolution time with a single instruction.
How long does that system call take?  That's easy...

Gordon