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

[Uzi Shvadron]

cbe-oss-dev-bounces+shvadron=il.ibm.com at ozlabs.org wrote on 15/10/2007
16:51:34:

> 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 <><

The SPU time base should be a system resource as the PPE time base is. That
is, it should run freely and be accessed by an API such as the spu-timer
API.
In order to provide a time value the spu-timer should always be active and
provide a 64 bits increment clock. This comes along with another idea to
provide a small service kernel on the SPUs. This kernel may provide a set
of services and environment variables to the applications. One of these
services would be the spu-timer API. I know this opens the stage to larger
discussion and there is a need to defined set of requirements. Note though
that the above issues may lead to such solution. If such a kernel is
created there will be no need to deal with the timer at the Linux kernel
level.

Uzi Shvadron

> >
> > 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.
>
>
> _______________________________________________
> cbe-oss-dev mailing list
> cbe-oss-dev at ozlabs.org
> https://ozlabs.org/mailman/listinfo/cbe-oss-dev