lkml.org 
[lkml]   [2003]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [2.4][PATCH] Xeon HT - SMT+SMP interrupt balancing
Arjan van de Ven wrote:
> 1) This got fixed in version 0.07

Thank you, Arjan -- let's see how it does. Hmm, I see you added a
ROTATE policy for timer. Ok, I edited your classify.c to add my storage
controller -- just to ensure everything is properly classified.

I get this result:

CPU0 CPU1 CPU2 CPU3
0: 7502 48699 48048 49595 IO-APIC-edge timer
1: 2 0 0 0 IO-APIC-edge keyboard
2: 0 0 0 0 XT-PIC cascade
8: 1 0 0 0 IO-APIC-edge rtc
15: 4 0 0 1 IO-APIC-edge ide1
16: 0 0 0 0 IO-APIC-level usb-uhci
19: 0 0 0 0 IO-APIC-level usb-uhci
24: 21061496 0 0 0 IO-APIC-level eth3
27: 21 0 732 0 IO-APIC-level eth2
31: 374 11363 0 0 IO-APIC-level eth0
48: 2716 0 1328 566 IO-APIC-level dpti0
NMI: 0 0 0 0
LOC: 153702 153699 153699 153635
ERR: 0
MIS: 0

So, the timer now migrates, but IRQ 24 isn't even shared by the
sibling, let alone the other "pair". Well, all these interfaces are
GigE -- 2 fiber, 2 copper -- so, I re-classified "eth" as GIGE and
didn't see any improvement; however, if I follow your policy correctly,
shouldn't the sibling get some usage in either case?

In any case, I consider the above behavior undesirable over time. CPU0
is handling most of the system while CPU1 contributes little. For
example, this snapshot:
top - 23:11:16 up 12 min, 1 user, load average: 0.26, 0.35, 0.19
Tasks: 49 total, 3 running, 46 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.8% user, 34.8% system, 0.0% nice, 64.4% idle
Cpu1 : 0.0% user, 0.0% system, 0.0% nice, 100.0% idle
Cpu2 : 15.5% user, 4.1% system, 0.0% nice, 80.5% idle
Cpu3 : 6.7% user, 2.4% system, 0.0% nice, 90.9% idle
Mem: 2068752k total, 477636k used, 1591116k free, 5156k buffers
Swap: 2097136k total, 0k used, 2097136k free, 36720k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ #C COMMAND
3 root 19 19 0 0 0 R 0.0 0.0 0:00.21 0
ksoftirqd_CPU0
1206 nobody 15 0 359m 359m 1724 R 29.3 17.8 3:33.23 3 ntop
1221 root 12 0 992 992 816 R 0.4 0.0 0:00.94 2 top
1 root 9 0 228 228 196 S 0.0 0.0 0:09.40 3 init


I appreciate your help, Arjan. Am I missing something?

> 2) You are talking a whopping 100 irq's per second, which is like about
> no interrupts... I doubt you can find a scenario where 100 irq's per
> second matter.... ;)

If I understand you correctly, I agree 100/s is negligible. But, I
think I see more than that on this lightly loaded machine:
'vmstat 1'
procs -----------memory---------- ---swap-- -----io---- --system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
1 0 0 1569188 5708 36728 0 0 11 3 3464 4614 6
11 83 0
0 0 0 1569184 5708 36728 0 0 0 0 14560 23163 6
10 84 0
0 0 0 1569184 5708 36728 0 0 0 0 14284 23734 8
11 81 0
1 0 0 1569184 5708 36728 0 0 0 0 14292 23617 5
10 85 0
0 0 0 1569160 5732 36728 0 0 0 64 14426 23771 6
12 82 0


Again, am I missing something?

Thanks again,
Ken Beaty
--
ken@nova.org / / /| / / / | /
GPG KeyID: 09209FA2 (on KeyServer) / / / | / / / |/
http://members.nova.org/~ken/index.html / / / | / / / /|
Running Slackware 8.0 & SMP kernel 2.4.23.../___ _/_ / |/ /__/ / |

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:59    [W:0.043 / U:9.476 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site