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

[Arnd Bergmann]

Please ignore the attachment I sent with my previous mail, it should not
have been in there. Sorry for spamming everyone.

	Arnd <><

On Monday 15 October 2007, Arnd Bergmann wrote:
> 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.