From: Andrew Theurer <habanero@us.ibm.com>
To: nitin.a.kamble@intel.com
Cc: "Martin J. Bligh" <mbligh@aracnet.com>,
linux-kernel@vger.kernel.org, jamesclv@us.ibm.com
Subject: RE: [PATCH][2.4] generic cluster APIC support for systems with more than 8 CPUs
Date: Tue, 7 Jan 2003 16:42:39 -0600 [thread overview]
Message-ID: <200301071642.39321.habanero@us.ibm.com> (raw)
>Hi Martin,
> Would somebody get a chance to try the kirq patch out? If yes, please
>let me know, how the patch did on your systems. Did your guys find any
>issues with it? I will also appreciate more comments.
>
>Thanks & Regards,
>Nitin
Nitin,
I am seeing if I can get together a test for Netbench with/without your patch.
Looking at the patch, I would expect a slight increase in performance. I'll
let you know the results as soon as I have them.
I do have one question for you: Have you tested netperf using only one
gigabit adapter? If so, have you been able to max out the adapter when using
hyperthreading? If not, could you test this? So far I have not been able
to, while I can quite easily with no hyperthreading (in Netbench). This is
the case with both irq_balance and irq affinity. having ints processed by
one and only one logical CPU at one time really seems to bottleneck network
throughput. I'm sure some of this has to do with sharing those resources
among 2 logical CPUs, but I also wonder if int processing is just a lot
slower than P3 overall.
I am bringing this up, because I recall James Cleverdon having some code which
allows interrupts to be dynamically routed to two CPU destinations, a pair of
CPUs with consecutive CPU ID's. Interrupts are dynamically routed to the
least loaded CPU, and if both are idle, to the CPU with the lower CPUID. I
like this idea, because when in HT, if consecutive logical CPU ID's map to
one physical core, we get to use "whole" processor, and both destinations
share the cache. Anyway, just a thought.
-Andrew Theurer
next reply other threads:[~2003-01-07 22:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-07 22:42 Andrew Theurer [this message]
2003-01-11 4:28 ` James Cleverdon
-- strict thread matches above, loose matches on Subject: below --
2003-01-08 3:19 Kamble, Nitin A
2002-12-21 3:27 Nakajima, Jun
2002-12-21 4:43 ` Martin J. Bligh
2002-12-19 2:45 Pallipadi, Venkatesh
2002-12-19 4:14 ` James Cleverdon
2002-12-19 2:35 Pallipadi, Venkatesh
2002-12-19 3:10 ` Martin J. Bligh
2002-12-19 1:05 Pallipadi, Venkatesh
2002-12-19 1:32 ` James Cleverdon
2002-12-18 22:36 Pallipadi, Venkatesh
2002-12-18 23:26 ` Christoph Hellwig
2002-12-18 23:41 ` William Lee Irwin III
2002-12-18 23:59 ` Martin J. Bligh
2002-12-19 0:24 ` Martin J. Bligh
2002-12-20 2:04 ` James Cleverdon
2002-12-20 8:00 ` Christoph Hellwig
2002-12-20 11:24 ` William Lee Irwin III
2002-12-20 11:29 ` William Lee Irwin III
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=200301071642.39321.habanero@us.ibm.com \
--to=habanero@us.ibm.com \
--cc=jamesclv@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.com \
--cc=nitin.a.kamble@intel.com \
/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
all inboxes | Powered by JetHome®