public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ken <ken@nova.org>
To: arjanv@redhat.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [2.4][PATCH] Xeon HT - SMT+SMP interrupt balancing
Date: Thu, 11 Dec 2003 23:39:29 -0500	[thread overview]
Message-ID: <3FD94681.3090008@nova.org> (raw)
In-Reply-To: <1071161984.5219.4.camel@laptop.fenrus.com>

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.../___ _/_ /   |/  /__/  / |


  reply	other threads:[~2003-12-12  4:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-11 16:44 [2.4][PATCH] Xeon HT - SMT+SMP interrupt balancing Ken
2003-12-11 16:59 ` Arjan van de Ven
2003-12-12  4:39   ` Ken [this message]
2003-12-12  9:34     ` Arjan van de Ven
2003-12-11 17:16 ` Martin J. Bligh
2003-12-12 19:47   ` Ken
2003-12-12 22:17     ` Martin J. Bligh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3FD94681.3090008@nova.org \
    --to=ken@nova.org \
    --cc=arjanv@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox