[Cbe-oss-dev] ps3vram performance

[Siarhei Siamashka]

On Monday 19 October 2009, Geoff Levand wrote:
> On 10/17/2009 06:20 AM, Siarhei Siamashka wrote:
> > But I still wonder if CPU spinning while waiting for DMA completion can
> > be done in a way, which is more friendly than udelay to the other HW
> > thread (Cell has something like hyperthreading, right?).
>
> The use of msleep() is so that the scheduler gets called
> while waiting.

When we have to wait only 0.1 ms for the DMA transfer to complete, adding
msleep which sleeps 1.0 ms minimum (or even more, depending on the scheduling)
is going to kill the performance for sure. Fortunately with your patch, msleep
is now never reachable in normal conditions and can't harm the performance.

An interesting thing to investigate is the "PPE Multithreading" section
of "Cell Broadband Engine Programming Handbook". Looks like it should be
possible to tune the priority of the current HW thread so that it will 
dispatch only one instruction per 32 instructions from the other HW thread.
TSRL and TSCR registers should control this.

This way, busylooping for 0.1 ms will still let the other HW thread to run
almost at full speed.

But I haven't found any useful references to TSRL and TSCR in the kernel
sources. How can they be accessed? Will hypervisor even allow tweaking thread
priorities?

That said, the handling of the each 256KiB block takes ~0.7 ms total, so
waiting for DMA transfer to complete is just a small fraction of time
for /dev/ps3vram read operation. So we are not saving much by being more easy
on CPU here (maybe just ~10% can be saved).

> VRAM IO speed isn't the most important 
> thing the system needs to do.

I depends.

-- 
Best regards,
Siarhei Siamashka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.ozlabs.org/pipermail/cbe-oss-dev/attachments/20091028/200dbe63/attachment.pgp>