From: Arjan van de Ven <arjanv@redhat.com>
To: Ken <ken@nova.org>
Cc: arjanv@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [2.4][PATCH] Xeon HT - SMT+SMP interrupt balancing
Date: Fri, 12 Dec 2003 10:34:24 +0100 [thread overview]
Message-ID: <20031212093424.GA12446@devserv.devel.redhat.com> (raw)
In-Reply-To: <3FD94681.3090008@nova.org>
On Thu, Dec 11, 2003 at 11:39:29PM -0500, Ken wrote:
> Arjan van de Ven wrote:
> >1) This got fixed in version 0.07
> 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?
No. Ethernet (and esp gigabit) has significant performance benefits from
being (and staying) on one cpu. What matters are lots of cacheline bounces,
and (even worse) packet(fragment) reordering that can happen if it moves around.
>
> 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
your machine is very very idle. Also remember that with modern machines,
even if a machine is 0% you probably can keep adding load to it for a while,
because then you are increasing "batching" which is very very cache
efficient operation, with the current differences between L1/L2 cache speed
and main memory speed it's not unlikely you can do 2x or 3x more work than
you do the moment idle hits 0%.
> procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
> 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
this is a sign you may want to enable IRQ mitigation in your network
driver to increase batching (unless your application is very latency bound)
Greetings,
Arjan van de Ven
next prev parent reply other threads:[~2003-12-12 9:34 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
2003-12-12 9:34 ` Arjan van de Ven [this message]
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=20031212093424.GA12446@devserv.devel.redhat.com \
--to=arjanv@redhat.com \
--cc=ken@nova.org \
--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