adding accuracy to random timers on PPC - new config option or runtime overhead?
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
Signature · 4 lines
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: [email protected]
Quoted 4 lines · Chris Friesen
I'm looking at putting in PPC-specific code in
add_timer_randomness()that would be similar to the x86-specific stuff.
Quoted 8 lines
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.
Signature · 1 line
Ignacio Vazquez-Abrams <[email protected]>
Quoted 5 lines · Ignacio Vazquez-Abrams
Quoted 3 lines · Chris Friesen
I'm looking at putting in PPC-specific code in
add_timer_randomness()that would be similar to the x86-specific stuff.
Quoted 8 lines
Quoted 4 lines
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.
Signature · 4 lines
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: [email protected]
Quoted 11 lines · Chris Friesen
Quoted 9 lines · Ignacio Vazquez-Abrams
Quoted 7 lines · 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?
Quoted 8 lines
Quoted 3 lines
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.
Signature · 1 line
Ignacio Vazquez-Abrams <[email protected]>
Quoted 8 lines · 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?
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.