[Cbe-oss-dev] SPU threads

Arnd Bergmann arnd at arndb.de
Wed May 30 00:37:04 EST 2007


On Tuesday 29 May 2007, Nicolas Morey-Chaisemartin wrote:
> My question may seem stupid, but i'm quite new to the kernel sources and 
> i'm still lost in them.
> I was wondering if the current kernel was binding a SPU thread to a 
> unique SPE or if the scheduler was able to move it from one to another? 
> I had a look to the kernel sources and it seems it is able to move SPU 
> thread (i've been told it was not)

It's a complicated topic.

First of all, there is a difference between an SPU context (which gets
loaded on an SPU), and a thread that calls the spu_run syscall for that
context.

Normally, the kernel is free to move the context around, but

* it will try to run it on the same chip that the thread run on
  for the PPU.
* You can force the context to run on a specfic NUMA node (i.e.
  chip) using numactl/libnuma. It can still be scheduled to any
  of the eight (or six) SPUs visible to Linux
* You can create a nonschedulable context that will never be removed
  from an SPU once it starts running there
* with the SDK-2.1 level (not yet in 2.6.21), you can give affinity
  hints to tell the kernel to colocate contexts, meaning they are
  scheduled to physically close SPUs to speed up communication.
  Note that this does not work on the PS3, which does not expose
  physical characteristics to the operating system.

> Assuming that kernel is still in development for the Cell, i was 
> wondering what are the main axes of work to improve linux on Cell. I may 
> not be really usefull as I lack some experience (I'm still student), but 
> i'm really interested in system development and as i've been a linux 
> user for quite a lot now, I would like to bring some help if I can.

You're welcome to help. As a start, you should look at the kernelnewbies.org
web site for general hints and then study the source code. If you find bugs,
submit patches, even if you are not sure that they fix the problem. Or even
better, when you don't understand a piece of code, try to write documentation
for it (google for kerneldoc). That will help you understand it, and also the
next person that reads the same code.

	Arnd <><



More information about the cbe-oss-dev mailing list