[Cbe-oss-dev] [PATCH 1/5] MARS: yield in workload queue wait busy loop
Kazunori Asayama
asayama at sm.sony.co.jp
Wed Jul 16 01:22:01 EST 2008
Arnd Bergmann wrote:
> On Tuesday 15 July 2008, Yuji Mano wrote:
>> @@ -194,9 +195,8 @@ int workload_queue_wait(struct mars_work
>> MARS_CHECK_RET(queue->block[block].state[index] !=
>> MARS_WORKLOAD_STATE_NONE, MARS_ERROR_STATE);
>>
>> - while (*(volatile uint8_t *)&queue->block[block].state[index] !=
>> - MARS_WORKLOAD_STATE_FINISHED) {
>> - }
>> + while (queue->block[block].state[index] != MARS_WORKLOAD_STATE_FINISHED)
>> + sched_yield();
>>
>> return MARS_SUCCESS;
>> }
>
> I think you should try to avoid busy loops altogether. Doing sched_yield()
> here (or anywhere else) will not give you the right behaviour. When you are
> waiting for a value in memory to change, basing your waiting primitive on
> futex should give you the best performance.
>
> If you don't want to write the futex code yourself, you can use a
> pthread_cond_t variable for waiting, but you can't currently use those
> from an SPU, unlike futexes, which you can access using the SPU syscall
> support in the kernel.
MARS assumes (near) realtime and/or interactive applications, so
synchronization functions tend to be frequently called. Thus we'd like
to avoid stopping an SPE(SPU syscall causes stop&signal) when
synchronization objects are used. Instead, if the SPE stalls on
synchronization, MARS implicitly switches to another runnable MARS task
without stopping the SPE, so that the SPE's usage increases. In the
other words, this behavior is one of major advantages of MARS.
This is the reason why we choosed memory based synchronization for MARS.
Do you have any suggestion?
--
(ASAYAMA Kazunori
(asayama at sm.sony.co.jp))
t
More information about the cbe-oss-dev
mailing list