All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.