[Top] [All Lists]

Re: Problems with CONFIG_PREEMPT

To: Jun Sun <>
Subject: Re: Problems with CONFIG_PREEMPT
From: Colin.Helliwell@Zarlink.Com
Date: Thu, 19 Dec 2002 09:10:40 +0000
Original-recipient: rfc822;
Thanks for the patch, but unfortunately the problem is still the same. I'm
not sure whether it occurs as a result of interrupts, or just after a
certain amount of scheduler 'activity' as it sits there copying the initrd
into ram disk. A few interrupts are enabled, but its only the MIPS timer
which should be generating any interrupts at that point (I'll check that,
in case its relevant).
I presume the change from "sti()" to "__sti()" was a semantic (or SMP)
thing, since the former is #defined to the latter anyway? Please note also
the following modification which was required to 2.4.19:

diff -u -p -r1.1 -r1.2
--- scratch/include/asm-mips/hardirq.h    2002/09/26 15:58:11     1.1
+++ scratch/include/asm-mips/hardirq.h    2002/12/12 13:15:03     1.2
@@ -42,7 +42,7 @@
 #define irq_exit(cpu, irq)   (local_irq_count(cpu)--)

 #define synchronize_irq()    barrier();
+#define release_irqlock(cpu) do { } while (0)

 #include <asm/atomic.h>

(We had a look at the 2.5 (head) kernel, but this seems to have some wrong
coding, and doesn't build straight off. Things like duplicate #defines
ALIGN and a conditional branch instruction with only one operand!)

                      Jun Sun                                                   
                      <>            To:       
                      Sent by:                     cc:,,                    
                      linux-mips-bounce@lin        Subject:  Re: Problems with 
                      17-Dec-2002 06:03 PM                                      

On Tue, Dec 17, 2002 at 08:27:16AM +0000, Colin.Helliwell@Zarlink.Com
> NEW_TIME_C is set. URL to the patch is:


There are some bits missing.  Not sure if it is related to your problem or

Robert, please take the MIPS preemptible kernel update patch.

> We ultimately want to add in real-time support, such as Ingo's O(1)
> scheduler - if this is 'complete' for MIPS.

O(1) shortens process dispatching time, usually not a big time saver
unless you have *lots* of process and/or you are doing frequent context

Another patch which is probably more important is the Ingo's breaking
selected big lock patch.  That will preemption work more effectively.

> I don't know if it would be
> better just to go for this in one hit, or if we'd need the preemption
> sorted out anyway first.

You do have to sort them out one by one.  (Or you get them all by becoming
mvista customer. :-0)

> Or should we just go to a 2.5.x kernel instead?

We'd love to have more people bang on 2.5 MIPS *grin* ...


<Prev in Thread] Current Thread [Next in Thread>