adding accuracy to random timers on PPC - new config option or runtime overhead?

adding accuracy to random timers on PPC - new config option or runtime overhead?

[Chris Friesen]

I'm looking at putting in PPC-specific code in add_timer_randomness() that would
be similar to the x86-specific stuff.

The problem is that the PPC601 uses real time clock registers while the other
PPC chips use a timebase register, so two different versions will be required.
Should I try and identify at runtime which it is (which would be extra
overhead), or should I add another config option to the kernel?

Thanks,

Chris

-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: adding accuracy to random timers on PPC - new config option or runtime overhead?

[Ignacio Vazquez-Abrams]

On Wed, 22 Aug 2001, Chris Friesen wrote:

>
> I'm looking at putting in PPC-specific code in add_timer_randomness() that would
> be similar to the x86-specific stuff.
>
> The problem is that the PPC601 uses real time clock registers while the other
> PPC chips use a timebase register, so two different versions will be required.
> Should I try and identify at runtime which it is (which would be extra
> overhead), or should I add another config option to the kernel?
>
> Thanks,
>
> Chris

How about determining which one to use at boot time? That way there's no
overhead, and there's no need to have yet another config option which probably
doesn't need to be there.

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>

Re: adding accuracy to random timers on PPC - new config option or runtime overhead?

[Chris Friesen]

Ignacio Vazquez-Abrams wrote:
> 
> On Wed, 22 Aug 2001, Chris Friesen wrote:
> > I'm looking at putting in PPC-specific code in add_timer_randomness() that would
> > be similar to the x86-specific stuff.
> >
> > The problem is that the PPC601 uses real time clock registers while the other
> > PPC chips use a timebase register, so two different versions will be required.
> > Should I try and identify at runtime which it is (which would be extra
> > overhead), or should I add another config option to the kernel?

> How about determining which one to use at boot time? That way there's no
> overhead, and there's no need to have yet another config option which probably
> doesn't need to be there.

As far as I can see there will still be some extra overhead.  We'd need an extra
conditional that wouldn't be there with the config option.  Granted, one
conditional shouldn't be too expensive, especially since we'll always be picking
the same branch.

-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: adding accuracy to random timers on PPC - new config option or runtime overhead?

[Ignacio Vazquez-Abrams]

On Wed, 22 Aug 2001, Chris Friesen wrote:

> Ignacio Vazquez-Abrams wrote:
> >
> > On Wed, 22 Aug 2001, Chris Friesen wrote:
> > > I'm looking at putting in PPC-specific code in add_timer_randomness() that would
> > > be similar to the x86-specific stuff.
> > >
> > > The problem is that the PPC601 uses real time clock registers while the other
> > > PPC chips use a timebase register, so two different versions will be required.
> > > Should I try and identify at runtime which it is (which would be extra
> > > overhead), or should I add another config option to the kernel?
>
> > How about determining which one to use at boot time? That way there's no
> > overhead, and there's no need to have yet another config option which probably
> > doesn't need to be there.
>
> As far as I can see there will still be some extra overhead.  We'd need an extra
> conditional that wouldn't be there with the config option.  Granted, one
> conditional shouldn't be too expensive, especially since we'll always be picking
> the same branch.

If the versions of the functions aren't too large then you may be able to get
away with putting in both functions and then using a function pointer to
select which one to use.

-- 
Ignacio Vazquez-Abrams  <ignacio@openservices.net>

Re: adding accuracy to random timers on PPC - new config option or runtime overhead?

[Gabriel Paubert]

On Wed, 22 Aug 2001, Chris Friesen wrote:

> 
> I'm looking at putting in PPC-specific code in add_timer_randomness() that would
> be similar to the x86-specific stuff.
> 
> The problem is that the PPC601 uses real time clock registers while the other
> PPC chips use a timebase register, so two different versions will be required.
> Should I try and identify at runtime which it is (which would be extra
> overhead), or should I add another config option to the kernel?

Look at how it's done in do_gettimeofday (expand the macros). Note that
the USE_RTC was not yet perfect last time I looked at it: it should only
perform a test whenever 601 support is enabled (there are so many problems
with 601).

Don't forget that in the case of a 601, you have to shift the least
significant word right by 7 bits since the register increments by 128
every 128 nanoseconds. But the upper word changes more often...

However, it would perhaps be better to define the code as a macro in
asm-${ARCH}/whatever.h and fall back to jiffies in case the macro is not
defined. Arch dependent ifdef'ed code should be avoided.

	Gabriel.