john cooper wrote:
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.
Manish Lachwani mentioned to me that he faced the same issue
with the MIPS RT support and that when he discussed
it with Ingo that the solution was for include/asm-ppc/tlb.h
to include/asm-generic/tlb-simple.h when PREEMPT_RT is turned on.
The patch does this for the #ifdef CONFIG_PPC_STD_MMU case,
but not for the #else case. I don't know which case is used
for the Ampro board.
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.
I am glad to see the instrumentation and measurement related code
in your patch. (My patch of last week ("Frank's patch") is lacking
that code.)
Other differences between the two patches are:
arch/ppc/syslib/i8259.c
Frank neglected to convert i8259_lock to a raw spinlock.
arch/ppc/kernel/signal.c
John added an enable of irqs in do_signal() #ifdef CONFIG_PREEMPT_RT
arch/ppc/kernel/traps.c
John added an enable of irqs and preempt_check_resched() in _exception().
various files
Frank added the intrusive variable tb_to_us for use by cycles_to_usec()
and added an ugly #ifdef in cycles_to_usec().
John hard-coded cpu_khz for one specific board so that no change would
be needed in cycles_to_usec().
various files
John has the mmu_gather fix that is described above.
John's patch and Frank's patch are otherwise mostly the same, except for
the differences that result from being based on different kernel
versions. I am glad to see that because it means that two sets of
eyes have agreed.
Frank's patch may have missed some EXPORT_SYMBOL()s in arch/ppc/lib/locks.c.
I'll check those over again tomorrow.
-john
-Frank
--
Frank Rowand <[EMAIL PROTECTED]>
MontaVista Software, Inc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
