From: Arthur Kepner <akepner@sgi.com>
To: "David S. Miller" <davem@davemloft.net>
Cc: Greg Banks <gnb@sgi.com>,
hadi@cyberus.ca, jesse.brandeburg@intel.com, netdev@oss.sgi.com
Subject: NAPI and CPU utilization [was: NAPI, e100, and system performance problem]
Date: Tue, 19 Apr 2005 13:38:20 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.61.0504191210040.15052@linux.site> (raw)
In-Reply-To: <20050419113657.7290d26e.davem@davemloft.net>
[Modified the subject line in order to not distract from
Jesse's original thread.]
On Tue, 19 Apr 2005, David S. Miller wrote:
> On Tue, 19 Apr 2005 15:55:35 +1000
> Greg Banks <gnb@sgi.com> wrote:
>
> > > How do you recognize when system resources are being poorly utilized?
> >
> > An inordinate amount of CPU is being spent running around polling the
> > device instead of dealing with the packets in IP, TCP and NFS land.
> > By inordinate, we mean twice as much or more cpu% than a MIPS/Irix
> > box with slower CPUs.
>
> You haven't answered the "how" yet.
>
> What tools did you run, what did those tools attempt to measure, and
> what results did those tools output for you so that you could determine
> your conclusions with such certainty?
>
I'm answering for myself, not Greg.
Much of the data is essentially from "/proc/". (We use a nice tool
called PCP to gather the data, but that's where PCP gets it, for the
most part.) But I've used several other tools to gather corroborating
data, including: the "kernprof" patch, "q-tools", an ad-hoc patch
which used "get_cycles()" to time things which were happening while
interrupts were disabled.
The data acquired with all these show that NAPI causes relatively
few packets to be processed per interrupt, so that expensive PIOs
are relatively poorly amortized over a given amount of input from
the network. (When I use "relative(ly)" above, I mean relative
what we see when using Greg's interrupt coalescence patch from
http://marc.theaimsgroup.com/?l=linux-netdev&m=107183822710263&w=2)
For example, following is a comparison of the number of packets
processed per interrupt and CPU utilization using NAPI and Greg's
interrupt coalescence patch.
This data is pretty old by now, it was gathered using 2.6.5 on an
Altix with 1GHz CPUs using the tg3 driver doing bulk data transfer
using nttcp. (I'm eyeballing the data from a set of graphs, so
it's rough...)
Link util [%] Packets/Interrupt CPU utilization [%]
NAPI Intr Coal. NAPI Intr Coal.
---------------------------------------------------------
25 2 3.5 45 17
40 4 6 52 30
50 4 6 60 36
60 4 7 75 41
70 6 10 80 36
80 6 16 90 40
85 7 16 100 45
100 - 17 - 50
I know more recent kernels have somewhat better performance,
(http://marc.theaimsgroup.com/?l=linux-netdev&m=109848080827969&w=2
helped, for one thing.)
The reason that CPU utilization is so high with NAPI is that
we're spinning, waiting for PIOs to flush (this can take an
impressively long time when the PCI bus/bridge is busy.)
I guess that some of us (at SGI) have seen this so often as
a bottleneck that we're surprised that it's not more generally
recognized as a problem, er, uh, "opportunity for improvement".
--
Arthur
next prev parent reply other threads:[~2005-04-19 20:38 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-18 6:11 NAPI, e100, and system performance problem Brandeburg, Jesse
2005-04-18 12:14 ` jamal
2005-04-18 15:36 ` Robert Olsson
2005-04-18 16:55 ` Arthur Kepner
2005-04-18 19:34 ` Robert Olsson
2005-04-18 20:26 ` jamal
2005-04-19 5:55 ` Greg Banks
2005-04-19 18:36 ` David S. Miller
2005-04-19 20:38 ` Arthur Kepner [this message]
2005-04-19 20:52 ` NAPI and CPU utilization [was: NAPI, e100, and system performance problem] Rick Jones
2005-04-19 21:09 ` David S. Miller
[not found] ` <20050420145629.GH19415@sgi.com>
2005-04-20 15:15 ` NAPI, e100, and system performance problem jamal
2005-04-22 11:36 ` Andi Kleen
2005-04-22 12:33 ` jamal
2005-04-22 17:21 ` Andi Kleen
2005-04-22 18:18 ` jamal
2005-04-22 18:30 ` Andi Kleen
2005-04-22 18:37 ` Arthur Kepner
2005-04-22 18:52 ` David S. Miller
[not found] ` <Pine.LNX.4.61.0504241845070.2934@linux.site>
2005-04-25 11:25 ` jamal
2005-04-25 18:51 ` David S. Miller
2005-04-25 11:41 ` jamal
2005-04-25 12:16 ` Jamal Hadi Salim
2005-04-22 19:01 ` jamal
2005-04-22 19:07 ` David S. Miller
2005-04-22 19:21 ` jamal
2005-04-23 20:50 ` Robert Olsson
2005-04-23 16:56 ` Robert Olsson
2005-04-22 23:28 ` Greg Banks
2005-04-22 23:40 ` Stephen Hemminger
2005-04-22 23:43 ` David S. Miller
2005-04-23 2:51 ` Stephen Hemminger
2005-04-23 17:54 ` Robert Olsson
2005-04-23 3:04 ` jamal
2005-04-23 17:14 ` Robert Olsson
2005-04-22 14:52 ` Robert Olsson
2005-04-22 15:37 ` jamal
2005-04-22 17:22 ` Andi Kleen
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=Pine.LNX.4.61.0504191210040.15052@linux.site \
--to=akepner@sgi.com \
--cc=davem@davemloft.net \
--cc=gnb@sgi.com \
--cc=hadi@cyberus.ca \
--cc=jesse.brandeburg@intel.com \
--cc=netdev@oss.sgi.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;
as well as URLs for NNTP newsgroup(s).