Jason Thorpe wrote:
>
> On Sep 21, 2006, at 9:41 PM, Frank Kardel wrote:
>
>> Jason Thorpe wrote:
>>>
>>> On Sep 19, 2006, at 6:31 AM, Garrett D'Amore wrote:
>>>
>>>> This was exactly the part I wasn't sure about.  I _think_ this 
>>>> should be
>>>> done (or similar logic) as part of timecounters -- i.e. each processor
>>>> needs to have some kind of synchronization -- probably implementing 
>>>> the
>>>> tc_pps method for timecounters.  I'm not an alpha expert though, so 
>>>> I'm
>>>> not 100% sure.
>>>
>>> I think Frank needs to step in here and take a look.
>> Ok, I'll take a look at that. Solutions probably lie along the line 
>> of the TSC
>> code which is basically the old Mills strategy. Tests still need to 
>> be done
>> on actual hardware.
>
> Right, and it would be nice to update the kern_microtime.c version 
> (that includes all of the microset logic) so that we don't have to 
> replicate it N times :-)
>
Hmm, the thing is that kern_microtime (as any microtime) has died with 
with timecounters.
Nevertheless it should be possible (i havent checked yet) to build some 
kind of "cc" based
 counter using the cc bits. I need to look into that.

Do you know offhand how many cc based implementation exist (I know of
sparc, i386, and presumably alpha)?

The cc variant could probably be similar to tsc.c. Care must be take 
however that
though cc is a nice abstraction it has is drawbacks as these counters 
have very different
properties (see the discussion on power saving quirks of TSC). Also, 
calibration of cc
depends on IPI timing or strict locking (which timecounter tries to 
avoid). So while
using a cc seems very attractive there are risks associated with it like 
backwards going
time because of varying scalings coming from varying IPI timings. While 
MP TSC seems
to work for normal use it can fail (backwards time) in tight loops 
because of the IPI timing
effects. To cope with the we might need even tighter coordination in form of
locking. Using a hardware counter might be the better solution there. I 
am open to
ideas here.

Frank