[Cbe-oss-dev] [RFC] Reading Local Store base address from SPU using stop-and-signal with kernel support

[Uzi Shvadron]

Cédric Augonnet wrote on 23/05/2007 00:48:18:

> Hi all,
>
> Sometimes, the SPU needs to know where its Local Store is mapped on
> main memory. The issue is that the user would have to somehow
> explicitly supply that information to the SPU as far as i know.
> Therefore a library needing that base address would hardly get that
> information.
>
> I would have liked to have your opinion about using a stop-and-signal
> receiving some implicit support from the kernel in order to get it.
>


In the past there has been several discussions about passing environment
variables to the SPE at run time. One of the recent discussion was named "
[PATCH] libspe: elfspe: set argv[argc] = NULL" where Arnd suggested:

> How about simply passing an effective address pointer as the
> third argument to main?
>
> If we pass the arguments as
>
> int main(int argc, char *argv[], uint64_t env_ea);
>
> then those applications that really want to access the environment
> can do that through DMA.
>
>            Arnd <><


My opinion that in both cases might be found as inefficient. I would like
to suggest another option. The idea is to identify a set of environment
variables that will be passed to the application LS at load time. This can
be done in the form:

int main(int argc, char *argv[], uint64_p envp)

where envp points to this predefined structure. This structure should be
rather small (say, 128 or 256 bytes). Now data is available at run-time to
the SPE application without the need to do system calls or DMA. This
structure can be updated at any time if needed (like at context switch).
In particular this structure can contain the local store ea in main memory,
it can include the SPE physical ID that is needed by performance tools,
etc. and it can include a pointer to larger data sets in main memory that
may not fit into the limited LS.

Uzi Shvadron


> _______________________________________________
> cbe-oss-dev mailing list
> cbe-oss-dev at ozlabs.org
> https://ozlabs.org/mailman/listinfo/cbe-oss-dev