[Cbe-oss-dev] [PATCH 1/5] MARS: yield in workload queue wait busy loop

[Arnd Bergmann]

On Wednesday 16 July 2008, Kazunori Asayama wrote:
> Arnd Bergmann wrote:
> > What you describe is one of the features of futexes: When you use them
> > with atomic updates (load-locked/store-conditional), you only need to
> > do a system call if there are other threads that are waiting or that
> > you need to wait for.
> 
> If I understand correctly, it seems to be impossible that an SPE wakes
> a PPE thread up by using futex unless the SPE stops in order to do SPU
> syscall...

That is true, yes. My point was that most of the time, the SPE does not
have to wake up any other thread, and with futex it can find that out
without stopping.

This may not be the right thing to do in all cases, but it is at least
one way to avoid busy-loops on the PPE.

> > Another option would be to use the mailboxes for asynchronous communication
> > from the SPU to the PPU. In the fast path, you can normally use simple
> > memory accesses, but if you think the other PPU might be blocking, the SPU
> > has to write to the interrupt mailbox, so that the PPU can do a blocking
> > read on it.
> 
> I worry that the probability of the SPE's stall may significantly 
> increases because of use of mailboxes. We'll need to look into various 
> possible scenarios and to evaluate performance impact if we try to use 
> the mailboxes for this purpose. And we also need to consider about 
> MARS's task switches since the MARS doesn't take care of MFC's status 
> when switching tasks (yes, MARS's task switching is 'light weight'!); 
> that is, if a task A writes anything to the SPE's mailbox then MARS 
> switches the task A to another task B, the content of the mailbox still 
> exists until some PPE thread reads it. That means one task can cause 
> another task's stall even if they logically have no dependency.

I guess this basically means that the mailbox becomes useless for the
MARS tasks, right? If so, it would be good to use it for synchronization
of the MARS kernel itself.
Mailbox stalls should of course be avoided, but I suppose there is a way
to combine synchronization through atomic memory updates with mailbox
accesses to achieve this.

	Arnd <><