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

[Dean Burdick]

Uzi, I don't think we're proposing to change the existing default 
behavior, so the clock provided by the library will continue to represent 
wall time by default.  Any new behavior would be optional.

I like the idea of maintaining both the wall time and a delta.  This would 
allow us to provide both real time (for trace timestamps) and virtual time 
(for measurements/timers) at the same time with the library.

Dean Burdick
Cell Software Development
IBM Austin, TX
512-838-0264 T/L: 678-0264




Arnd Bergmann <arnd at arndb.de> 
10/22/2007 08:47 AM

To
Uzi Shvadron <SHVADRON at il.ibm.com>
cc
cbe-oss-dev at ozlabs.org, Dean Burdick/Austin/IBM at IBMUS
Subject
Re: [Cbe-oss-dev] Fwd: adding virtual SPU timers






On Monday 22 October 2007, Uzi Shvadron wrote:

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

I don't think we can get to the point where everybody agrees on a
common runtime environment beyond what is provided with libc, but it 
sounds
fair to have an (optional) library abstracts the use of the decrementer
in the same way that we have libraries for managing overlays and MFC tags.

The way you describe where you want to end up sounds like it would 
conflict
with Dean's work, as it suggests that that there needs to be a source for
real time instead of the 'virtual time' that Dean was asking for.

                 Arnd <><

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/cbe-oss-dev/attachments/20071022/de38b481/attachment.htm>