[Cbe-oss-dev] Fwd: adding virtual SPU timers

Arnd Bergmann arnd.bergmann at de.ibm.com
Tue Oct 16 00:42:44 EST 2007


Hi all,

Dean Burdick asked me to bring up this topic on the mailing list,
as he's a little too shy to ask himself. Apparently there is
a library that was written under the assumption that the SPE
decrementer runs only while the SPE itself is fetching code.

This is obviously an incorrect assumption, as the kernel
does not even know when or how long the SPE is stopped in
certain conditions, and therefore tries very hard to maintain
the illusion of absolute time values in the decrementer even
across reschedules.

The interesting question is now whether there is something we
can do in the kernel to make the library work in a useful way.

There are two separate problems that would need to get solved
for this:

1. Determine when to stop the decrementer:
The easiest way would be to have it running as long as the
thread is inside of the spu_run syscall, including reschedules,
but not while it is processing callbacks on the PPE that were
initiated by stop-and-signal or similar. Another option would
be to also stop the decrementer while the kernel is processing
syscalls or page faults on behalf of the SPE and it is waiting to
get restarted. Finally, we could stop the decrementer while the
context is taken off of a physical SPE, which would come down
to disabling the logic to fake real time.
Of course, we could have any combination of these three.

2. Find an interface to change the behavior:
The default behavior has to remain compatible with older kernels,
so a user application will need to ask for the change explicitly.
Possible interfaces include:
* a new file in spufs with a 0/1 value, like the signal{1,2}_type
  files
* a new flag to spu_create
* a new system call to query the time offset that the library 
  needs to subtract in order to get what it wants.
I don't really like any of these interface and would be happy
if someone came up with a better idea.

Also, I'd like to hear what kind of requirement other people
have so we can do the right thing and don't need another special
workaround for a specific use of the timers.

	Arnd <><

Dean Burdick wrote:
> The SPU timer library maintains a "software time base" in that it adds
> (whatever the decrementer value was) to a software counter on each
> decrementer interrupt.  This allows for the coexistence of an elapsed time
> clock and interval timers.  The library is shipping with SDK3.0 and is used
> by PDT, and the DaCS library, both of which are GA.
>
> The intent of the virtual clock provided by the library is to provide a
> measure of elapsed runtime for the calling thread, so I guess that means we
> would want to save and restore the decrementer value along with the rest of
> the thread context.  The one possible exception might be when the thread
> does a stop and signal to do a system call over on the PPU, since this time
> might be of interest when doing performance analysis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic00604.jpg
Type: image/jpeg
Size: 151959 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/cbe-oss-dev/attachments/20071015/76e64894/attachment.jpg>


More information about the cbe-oss-dev mailing list