On Tue, 6 Jul 2004, Martin Husemann wrote:

> On Tue, Jul 06, 2004 at 12:24:44AM -0500, Frederick Bruckman wrote:
>
>> It could say "about 1/10 second" or "about 10 seconds", or it could say
>> "short interval" and "long interval", and let the actual numbers be varied
>> (by experiment) for each port.
>
> Having those overridable per port sounds good.

We could make the short interval dynamic. It could be allowed to go 
longer when the predicted cycle counter matches reality, or shorter 
when it doesn't, within limits. There would be overhead, so the user 
should be able to turn that off, or configure to a fixed value. I 
think the long interval should be somewhere between 10 and 60 seconds, 
but I'm not clear on how to figure the optimum value.

>> Right. I don't know either. That's definitely the biggest possible
>> downside. For what it's worth, it doesn't *feel* any more sluggish.
>
> If the interval is tunable per port (and maybe via a kernel config option)
> we can experiment for the slower SMP machines. I have some ;-)

Good idea. If it's a kernel config, and if portmasters don't want to 
expose it to users, they can put it into Makefile.<machine> in the 
kernel config directory.

>> In order for cc_microset() to utilize a longer interval to calibrate the
>> ratio, it needs to know if the 32-bit counter has rolled over, and how
>> many times, and the only way to do that, is to track it on the short
>> interval.
>
> Maybe we can make this tunable per port too. There are counters with more
> than 32bit (which we currently mask to 32bit only) and there are archs that
> easily can calculate with 64bit values.

Yeah. I think now that ci_cc_microset_cc* should be a union type, so 
it can be treated as a 64bit value no matter if it was filled the hard 
way, or with a single instruction.

Frederick