public inbox for linux-smp@vger.kernel.org
 help / color / mirror / Atom feed
* About IO-APIC - General question
@ 2002-04-16  6:25 Peter H. Koenig
  2002-04-16 11:47 ` Klaas Zweck
  0 siblings, 1 reply; 5+ messages in thread
From: Peter H. Koenig @ 2002-04-16  6:25 UTC (permalink / raw)
  To: linux-smp

Hello,

from how I understood APIC it purpose on an SMP machine is to give all
processors the possibility to handle interrupts instead of one processor
responsible for them. So when running two jobs on an SMP machine a
non-working IO-APIC would turn into a performance disadvantage. Do I get
this right ? If yes, does anybody have a clue, how much difference this
could make when running IO-intensive programms ? single or two digit
percentages ?

Thanks
Pete



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: About IO-APIC - General question
  2002-04-16  6:25 About IO-APIC - General question Peter H. Koenig
@ 2002-04-16 11:47 ` Klaas Zweck
  2002-05-03 16:27   ` Peter H. Koenig
  0 siblings, 1 reply; 5+ messages in thread
From: Klaas Zweck @ 2002-04-16 11:47 UTC (permalink / raw)
  To: Peter H. Koenig; +Cc: linux-smp

hi peter,

i made some test on a linux-smp machine(kernel 2.4.9).
i had one process just doing some calculation on prim numbers.
i locked this to cpu 1 and disabled all interrupts on cpu 1.
( in fact i routed all to cpu 0 )
then i started a make -j4 bzImage job in a remote
shell to produce file i/o and network interrupts.
i restricted all processes except the one doing the calculation
from cpu 1 and delivered all interrupts only to cpu 0.

i had an total runtime for the calculating process of:
(with interrupts routed only to one cpu)

voyager:~/# time ./rt_prim_ohne_syscalls
real    0m42.111s
user    0m41.870s
sys     0m0.240s

voyager:~/# time ./rt_prim_ohne_syscalls
 
real    0m40.268s
user    0m40.190s
sys     0m0.080s
voyager:~/# time ./rt_prim_ohne_syscalls
 
real    0m40.068s
user    0m40.000s
sys     0m0.070s
 
average :
real:   0m40.815s 

in the same scenario as above but with irqs routed to all cpus
the calculationg process still locked to cpu 1 had a runtime of:


 
voyager:~/# time ./rt_prim_ohne_syscalls -rt
 
real    0m39.712s
user    0m39.680s
sys     0m0.030s
voyager:~/# time ./rt_prim_ohne_syscalls -rt
 
real    0m39.998s
user    0m39.720s
sys     0m0.270s
voyager:~/# time ./rt_prim_ohne_syscalls -rt
 
real    0m39.950s
user    0m39.900s
sys     0m0.050s
 
 
average:
real    0m39.886s


so its a measurable but small performance plus of 2.5 %.
but since i worked remote just network and i/o irqs occeured there were
no keyboard or mouse irqs in the system.


hope it helps a bit,
greetings,
klaas

Peter H. Koenig wrote:

>Hello,
>
>from how I understood APIC it purpose on an SMP machine is to give all
>processors the possibility to handle interrupts instead of one processor
>responsible for them. So when running two jobs on an SMP machine a
>non-working IO-APIC would turn into a performance disadvantage. Do I get
>this right ? If yes, does anybody have a clue, how much difference this
>could make when running IO-intensive programms ? single or two digit
>percentages ?
>
>Thanks
>Pete
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-smp" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: About IO-APIC - General question
  2002-04-16 11:47 ` Klaas Zweck
@ 2002-05-03 16:27   ` Peter H. Koenig
  2002-05-03 22:13     ` Mark Hounschell
  0 siblings, 1 reply; 5+ messages in thread
From: Peter H. Koenig @ 2002-05-03 16:27 UTC (permalink / raw)
  To: linux-smp

Hello,

Klaas, I would like to thank you for the data you provided.

From your first paragraph I take that there is the possibility of specifying
which processor(s) handle(s) interrupts manually.

Klaas Zweck wrote:
> i made some test on a linux-smp machine(kernel 2.4.9).
> i had one process just doing some calculation on prim numbers.
> i locked this to cpu 1 and disabled all interrupts on cpu 1.
> ( in fact i routed all to cpu 0 )
> then i started a make -j4 bzImage job in a remote
> shell to produce file i/o and network interrupts.
> i restricted all processes except the one doing the calculation
> from cpu 1 and delivered all interrupts only to cpu 0.

Is it neccessary specifying this for getting interrupt sharing working ?

My interrupts statistics table shows that the interrrupts are handled by
one
CPU solely:

$ cat /proc/interrupts 
           CPU0       CPU1       
  0:      84363          0    IO-APIC-edge  timer
  1:          2          0    IO-APIC-edge  keyboard
  2:          0          0          XT-PIC  cascade
  8:          1          0    IO-APIC-edge  rtc
 11:       1661          0   IO-APIC-level  eth0
 14:       8741          0    IO-APIC-edge  ide0
 15:          2          0    IO-APIC-edge  ide1
NMI:          0          0 
LOC:      84283      84281 
ERR:          0
MIS:          0

This differs somehow from the (old) IO-APIC documentation where in the
case
of SMP-boards the IRQ load is shared between the processors.

This problem occurs on a Supermicro P4DC6 using an unreleased bios
release
(without that so far the APIC has not been recognized at all), the MPS
specification set to version 1.1 in the bios using kernel 2.4.10, 2.4.17
and
2.4.18.

As some of the applications we run are quite Network or IO-intensive, we
would like to take advantage of the IRQ sharing.

Any suggestions ?

Pete



-- 
Dipl.-Chem. Peter H. Koenig                               
FB 6 - Theoretische Physik    Tel.: +49 5251 60 2332   
Universitaet Paderborn        Fax:  +49 5251 60 3435   
Pohlweg 55                                             
33098 Paderborn

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: About IO-APIC - General question
  2002-05-03 16:27   ` Peter H. Koenig
@ 2002-05-03 22:13     ` Mark Hounschell
  2002-05-18 10:59       ` Peter H. Koenig
  0 siblings, 1 reply; 5+ messages in thread
From: Mark Hounschell @ 2002-05-03 22:13 UTC (permalink / raw)
  To: Peter H. Koenig; +Cc: linux-smp

"Peter H. Koenig" wrote:
> 
> Hello,
> 
> Klaas, I would like to thank you for the data you provided.
> 
> >From your first paragraph I take that there is the possibility of specifying
> which processor(s) handle(s) interrupts manually.
> 
> Klaas Zweck wrote:
> > i made some test on a linux-smp machine(kernel 2.4.9).
> > i had one process just doing some calculation on prim numbers.
> > i locked this to cpu 1 and disabled all interrupts on cpu 1.
> > ( in fact i routed all to cpu 0 )
> > then i started a make -j4 bzImage job in a remote
> > shell to produce file i/o and network interrupts.
> > i restricted all processes except the one doing the calculation
> > from cpu 1 and delivered all interrupts only to cpu 0.
> 
> Is it neccessary specifying this for getting interrupt sharing working ?
> 
> My interrupts statistics table shows that the interrrupts are handled by
> one
> CPU solely:
> 
> $ cat /proc/interrupts
>            CPU0       CPU1
>   0:      84363          0    IO-APIC-edge  timer
>   1:          2          0    IO-APIC-edge  keyboard
>   2:          0          0          XT-PIC  cascade
>   8:          1          0    IO-APIC-edge  rtc
>  11:       1661          0   IO-APIC-level  eth0
>  14:       8741          0    IO-APIC-edge  ide0
>  15:          2          0    IO-APIC-edge  ide1
> NMI:          0          0
> LOC:      84283      84281
> ERR:          0
> MIS:          0
> 
> This differs somehow from the (old) IO-APIC documentation where in the
> case
> of SMP-boards the IRQ load is shared between the processors.
> 
> This problem occurs on a Supermicro P4DC6 using an unreleased bios
> release
> (without that so far the APIC has not been recognized at all), the MPS
> specification set to version 1.1 in the bios using kernel 2.4.10, 2.4.17
> and
> 2.4.18.
> 
> As some of the applications we run are quite Network or IO-intensive, we
> would like to take advantage of the IRQ sharing.
> 
> Any suggestions ?
> 
> Pete
There is an irq_balance patch floating around that works on this mother
board. I have 2 or 3 of these with the same symptom. It was resolved by
this irq_balance patch. I beleive it was
written by Ingo

Here it is

There is another on for irq0 (timer) but you won't need it for this MB

--- linux/kernel/sched.c.orig   Tue Feb  5 13:11:35 2002
+++ linux/kernel/sched.c        Tue Feb  5 13:12:48 2002
@@ -118,6 +118,11 @@
 #define can_schedule(p,cpu) \
        ((p)->cpus_runnable & (p)->cpus_allowed & (1 << cpu))
 
+int idle_cpu(int cpu)
+{
+       return cpu_curr(cpu) == idle_task(cpu);
+}
+
 #else
 
 #define idle_task(cpu) (&init_task)
--- linux/include/linux/sched.h.orig    Tue Feb  5 13:13:09 2002
+++ linux/include/linux/sched.h Tue Feb  5 13:14:00 2002
@@ -144,6 +144,7 @@
 
 extern void sched_init(void);
 extern void init_idle(void);
+extern int idle_cpu(int cpu);
 extern void show_state(void);
 extern void cpu_init (void);
 extern void trap_init(void);
--- linux/include/asm-i386/hardirq.h.orig       Tue Feb  5 13:10:39 2002
+++ linux/include/asm-i386/hardirq.h    Tue Feb  5 13:14:00 2002
@@ -12,6 +12,7 @@
        unsigned int __local_bh_count;
        unsigned int __syscall_count;
        struct task_struct * __ksoftirqd_task; /* waitqueue is too large
*/
+       unsigned long idle_timestamp;
        unsigned int __nmi_count;       /* arch dependent */
 } ____cacheline_aligned irq_cpustat_t;
 
--- linux/arch/i386/kernel/io_apic.c.orig       Tue Feb  5 13:10:37 2002
+++ linux/arch/i386/kernel/io_apic.c    Tue Feb  5 13:15:23 2002
@@ -28,6 +28,7 @@
 #include <linux/config.h>
 #include <linux/smp_lock.h>
 #include <linux/mc146818rtc.h>
+#include <linux/compiler.h>
 
 #include <asm/io.h>
 #include <asm/smp.h>
@@ -163,6 +164,86 @@
                        clear_IO_APIC_pin(apic, pin);
 }
 
+static void set_ioapic_affinity (unsigned int irq, unsigned long mask)
+{
+       unsigned long flags;
+
+       /*
+        * Only the first 8 bits are valid.
+        */
+       mask = mask << 24;
+       spin_lock_irqsave(&ioapic_lock, flags);
+       __DO_ACTION(1, = mask, )
+       spin_unlock_irqrestore(&ioapic_lock, flags);
+}
+
+#if CONFIG_SMP
+
+typedef struct {
+       unsigned int cpu;
+       unsigned long timestamp;
+} ____cacheline_aligned irq_balance_t;
+
+static irq_balance_t irq_balance[NR_IRQS] __cacheline_aligned
+                       = { [ 0 ... NR_IRQS-1 ] = { 1, 0 } };
+
+extern unsigned long irq_affinity [NR_IRQS];
+
+#endif
+
+#define IDLE_ENOUGH(cpu,now) \
+               (idle_cpu(cpu) && ((now) -
irq_stat[(cpu)].idle_timestamp > 1))
+
+#define IRQ_ALLOWED(cpu,allowed_mask) \
+               ((1 << cpu) & (allowed_mask))
+
+static unsigned long move(int curr_cpu, unsigned long allowed_mask,
unsigned long now, int
direction)
+{
+       int search_idle = 1;
+       int cpu = curr_cpu;
+
+       goto inside;
+
+       do {
+               if (unlikely(cpu == curr_cpu))
+                       search_idle = 0;
+inside:
+               if (direction == 1) {
+                       cpu++;
+                       if (cpu >= smp_num_cpus)
+                               cpu = 0;
+               } else {
+                       cpu--;
+                       if (cpu == -1)
+                               cpu = smp_num_cpus-1;
+               }
+       } while (!IRQ_ALLOWED(cpu,allowed_mask) ||
+                       (search_idle && !IDLE_ENOUGH(cpu,now)));
+
+       return cpu;
+}
+
+static inline void balance_irq(int irq)
+{
+#if CONFIG_SMP
+       irq_balance_t *entry = irq_balance + irq;
+       unsigned long now = jiffies;
+
+       if (unlikely(entry->timestamp != now)) {
+               unsigned long allowed_mask;
+               int random_number;
+
+               rdtscl(random_number);
+               random_number &= 1;
+
+               allowed_mask = cpu_online_map & irq_affinity[irq];
+               entry->timestamp = now;
+               entry->cpu = move(entry->cpu, allowed_mask, now,
random_number);
+               set_ioapic_affinity(irq, 1 << entry->cpu);
+       }
+#endif
+}
+
 /*
  * support for broken MP BIOSs, enables hand-redirection of PIRQ0-7 to
  * specific CPU-side IRQs.
@@ -653,8 +734,7 @@
 }
 
 /*
- * Set up the 8259A-master output pin as broadcast to all
- * CPUs.
+ * Set up the 8259A-master output pin:
  */
 void __init setup_ExtINT_IRQ0_pin(unsigned int pin, int vector)
 {
@@ -1174,6 +1254,7 @@
  */
 static void ack_edge_ioapic_irq(unsigned int irq)
 {
+       balance_irq(irq);
        if ((irq_desc[irq].status & (IRQ_PENDING | IRQ_DISABLED))
                                        == (IRQ_PENDING | IRQ_DISABLED))
                mask_IO_APIC_irq(irq);
@@ -1213,6 +1294,7 @@
        unsigned long v;
        int i;
 
+       balance_irq(irq);
 /*
  * It appears there is an erratum which affects at least version 0x11
  * of I/O APIC (that's the 82093AA and cores integrated into various
@@ -1268,19 +1350,6 @@
 }
 
 static void mask_and_ack_level_ioapic_irq (unsigned int irq) { /*
nothing */ }
-
-static void set_ioapic_affinity (unsigned int irq, unsigned long mask)
-{
-       unsigned long flags;
-       /*
-        * Only the first 8 bits are valid.
-        */
-       mask = mask << 24;
-
-       spin_lock_irqsave(&ioapic_lock, flags);
-       __DO_ACTION(1, = mask, )
-       spin_unlock_irqrestore(&ioapic_lock, flags);
-}
 
 /*
  * Level and edge triggered IO-APIC interrupts need different handling,
--- linux/arch/i386/kernel/irq.c.orig   Tue Feb  5 13:10:34 2002
+++ linux/arch/i386/kernel/irq.c        Tue Feb  5 13:11:15 2002
@@ -1076,7 +1076,7 @@
 
 static struct proc_dir_entry * smp_affinity_entry [NR_IRQS];
 
-static unsigned long irq_affinity [NR_IRQS] = { [0 ... NR_IRQS-1] =
~0UL };
+unsigned long irq_affinity [NR_IRQS] = { [0 ... NR_IRQS-1] = ~0UL };
 static int irq_affinity_read_proc (char *page, char **start, off_t off,
                        int count, int *eof, void *data)




-- 
Mark Hounschell
dmarkh@cfl.rr.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: About IO-APIC - General question
  2002-05-03 22:13     ` Mark Hounschell
@ 2002-05-18 10:59       ` Peter H. Koenig
  0 siblings, 0 replies; 5+ messages in thread
From: Peter H. Koenig @ 2002-05-18 10:59 UTC (permalink / raw)
  To: linux-smp

Hello,

 
Mark Hounschell <dmarkh@cfl.rr.com> wrote:
> There is an irq_balance patch floating around that works on this mother
> board. I have 2 or 3 of these with the same symptom. It was resolved by
> this irq_balance patch. I beleive it was
> written by Ingo
> 
> Here it is
> ....

Thanks, that worked. Now at least the ethernet IRQs are fielded by both
processors. However, the other IRQs are still handled by CPU0 solely:

           CPU0       CPU1       
  0:   25411781          0    IO-APIC-edge  timer
  1:          2          0    IO-APIC-edge  keyboard
  2:          0          0          XT-PIC  cascade
  8:          1          0    IO-APIC-edge  rtc
 11:     502144     505080   IO-APIC-level  eth0
 14:      82516          0    IO-APIC-edge  ide0
 15:          2          0    IO-APIC-edge  ide1
NMI:          0          0 
LOC:   25412978   25412977 
ERR:          0
MIS:          0

This differs for example from the table Vladimir G. Ivanovic
<vladimir@acm.org> showed in his posting "Re: Dual Processor":
>           CPU0       CPU1       
>  0:    1255948    1257289    IO-APIC-edge  timer
>  1:      15469      15349    IO-APIC-edge  keyboard
>  2:          0          0          XT-PIC  cascade
>  4:      11163      10377    IO-APIC-edge  serial
>  5:      79559      79534   IO-APIC-level  es1371, usb-uhci, usb-uhci
>  8:    9869264    9862018    IO-APIC-edge  rtc
>  9:      17601      17613   IO-APIC-level  sym53c8xx
> 10:     109682     109643   IO-APIC-level  eth0
> 11:         47         50   IO-APIC-level  sym53c8xx
> 12:     136004     138160    IO-APIC-edge  PS/2 Mouse
> 14:        224        134    IO-APIC-edge  ide0
> 15:      29773      28616    IO-APIC-edge  ide1
>NMI:          0          0 
>LOC:    2513322    2513376 
>ERR:          0
>MIS:          0

Does anybody have a suggestion for getting the IRQs for the harddisks
etc. fielded equally in this case ?

Pete

-- 
Dipl.-Chem. Peter H. Koenig	                          
FB 6 - Theoretische Physik    Tel.: +49 5251 60 2332   
Universitaet Paderborn        Fax:  +49 5251 60 3435   
Pohlweg 55                                             
33098 Paderborn

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2002-05-18 10:59 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-04-16  6:25 About IO-APIC - General question Peter H. Koenig
2002-04-16 11:47 ` Klaas Zweck
2002-05-03 16:27   ` Peter H. Koenig
2002-05-03 22:13     ` Mark Hounschell
2002-05-18 10:59       ` Peter H. Koenig

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox