Quote:
Is there some room for performance improvement?
Yes, and No.
There are some hardware bugs in the ATA controller pertaining to the ATA FIFO alarm, and the ATA state machine, in the MPC5200B which make UDMA disk access sort of dangerous.
However there is a
Linux patch written by Tim Yamin that enables it anyway; and sets some egregious BestComm ATA initiator priority to do it.. he and a few others report no problems, but I guarantee you will not be able to experience clear audio output while disk activity is happening :)
Also however there are
mails like this one which do not inspire confidence!
I personally approve the patch as it will show people there really is a problem :D
There is a way to get better performance; instead of using UDMA, use disk PIO4 mode, but use the BestComm engine to transfer data to and from the disk and FIFO under CPU control. This does not mean you will ever see 20MB/s (or anything near 33MB/s) but 8-10MB/s with the CPU not constantly engaged in marshalling disk activity is a good performance compromise.
Nobody has stepped up to the plate to port the DMA-assisted PIO operation to libata, so the performance will still suck until it's done. Ideally you'd implement PIO-DMA as a real PIO mode (therefore you could have Tim Yamin's patch installed and enabled, but use libata.nodma=1 to get DMA-assisted PIO)
DMA-assisted PIO is not some magic thing for the MPC5200B either, Intel AHCI and Silicon Image controllers implement something similar to offload certain disk activity (it's not possible to send ATA commands using UDMA, for example, so this can still be offloaded by passing the command block to the system DMA unit and having it shunt to the ATA controller, and the functionality exists basically so that in the event of nasty UDMA errors on a disk, reliable yet still reasonable operation can still be maintained on high performance servers (for instance, rebuilding a RAID array) using these controllers)