I've had this wierdity off and on where cpu bound tasks won't respond to ^C
or a kill running another higher priority CPU bound task will finally make it
see the signal - this seems to have gone away with 2.2.0 but I still do have
some strange something happening on one of my over night jobs it does the
same sort of thing - it takes over the cpu - as soon as I touch a key in the
morning everything comes right and all I see to show for it is a silly load
average.

So I went and looked at the signal delivery code and I realised that 
if you try and send a signal to a process that's running on another CPU 
it doesn't see the signal untill the cpu next gets rescheduled - whether this
has anything to do with the problems I've been seeing I don't know - (I'd expect
that signals would eventually be delivered at the next timer interrupt).

Anyway I've produced the following patch to force a reschedule to a CPU running
a process that has a signal delivered to it - to my purely subjective eye X
seems to be running faster but I suspect that that's all in my head :-)

While I have a lot of Unix kernel experience this is my first time hacking on
Linux so please show me any  stupid  mistakes in the following:

        thanks

        Paul Campbell
        [EMAIL PROTECTED]


--- linux-2.2.0-final/kernel/signal.c   Fri Dec 18 09:37:22 1998
+++ linux/kernel/signal.c       Mon Feb  1 22:17:49 1999
@@ -363,8 +363,31 @@
        }
 
        sigaddset(&t->signal, sig);
-       if (!sigismember(&t->blocked, sig))
+       if (!sigismember(&t->blocked, sig)) {
                t->sigpending = 1;
+#ifdef __SMP__
+               //
+               //      if the task is running on a different CPU 
+               //      force a reschedule on the other CPU - note that
+               //      the code below is a tad loose and might occasionally
+               //      wake the wrong CPU if we catch the process in the
+               //      process of changing - but no harm is done by that
+               //      other than forcing a rechedule of the wrong process
+               //
+               { 
+                       unsigned long flags;                                    //pwc
+                       extern spinlock_t runqueue_lock;                        //pwc
+                                                                               //pwc
+                       spin_lock_irqsave(&runqueue_lock, flags);               //pwc
+                       if (t->has_cpu && t->processor != smp_processor_id()) { //pwc
+                               t->need_resched = 1;                            //pwc
+                               smp_send_reschedule(t->processor);              //pwc
+                       }                                                       //pwc 
+                       spin_unlock_irqrestore(&runqueue_lock, flags);          //pwc
+               }                                                               //pwc
+                       
+#endif /* __SMP__ */
+       }
 
 out:
        spin_unlock_irqrestore(&t->sigmask_lock, flags);
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]

Reply via email to