Messages in this thread | | | Date | Wed, 23 Feb 2005 18:52:58 -0500 | From | john cooper <> | Subject | PPC RT Patch.. |
| |
Ingo, We've had a PPC port of your RT work underway with a focus on trace instrumentation. This is based upon realtime-preempt-2.6.11-rc2-V0.7.37-02. A diff is attached.
To the extent possible the tracing facilities are the same as your x86 work. In the process a few PPC/gcc issues needed to be resolved. There is also a bug fix contained for tlb_gather_mmu() which was causing debug assertions to be generated in a path which attempted to sleep with a non-zero preempt count.
This does build and function when SMP is configured, though we have not yet verified it on other than a uniprocessor. As a simplifying assumption, testing has thus far concentrated on the following modes:
PREEMPT_NONE - verify baseline regression
PREEMPT_RT && !PREEMPT_SMP - typical for an embedded RT PPC application
PREEMPT_RT && PREEMPT_SMP - kicks in live locking code which otherwise receives no coverage. This is functionally equivalent to the above config on a single CPU target thus no MP dynamic testing is achieved. Still quite useful IMHO.
The target used for development/testing is an Ampro EnCore PP1 which sports a 300Mhz MPC8245. For testing this boots with NFS as root. An mp3 decode at nice --20 is launched which requires just under 20% of the CPU to maintain an uninterrupted audio decode and output. To this a series of "du -s /" are launched to soak up excess CPU bandwidth. Perhaps not rigorous but a fair sanity check and load for the purpose at hand.
Under these conditions maximum scheduling latencies are seen in the 120-150us range. Note no attempt has yet been made to optimize arch specific paths and full trace instrumentation has been enabled.
I've written some logging code to help find problems such as the tlb issue above. As it has not been made general I've removed it from this patch. At some point I'll likely revisit this.
Comments/suggestions welcome.
-john
-- john.cooper@timesys.com
| |