From: Arthur Kepner <akepner@sgi.com>
To: "David S.Miller" <davem@davemloft.net>
Cc: mchan@broadcom.com, netdev@oss.sgi.com
Subject: Re: Perf data with recent tg3 patches
Date: Fri, 13 May 2005 16:57:51 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.61.0505131648140.14917@linux.site> (raw)
In-Reply-To: <20050512.211935.67881321.davem@davemloft.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1932 bytes --]
On Thu, 12 May 2005, David S.Miller wrote:
> ......
> The tg3_interrupt coalesce patch from me is supposed
> to be applied on top of my tagged status patch.
>
OK, but the "tagged status" patch and the "hw
coalescing infrastructure" patch aren't really
dependent, right?
In any case, I've repeated the measurements with
both patches. Same experiment as yesterday.
The data is in the attached graphs is labelled as follows:
---------------------------------------------------------
base : is a "vanilla" 2.6.12-rc3 kernel
base+[1]+...+[i] : "vanilla" 2.6.12-rc3 kernel + patches
as labelled below
[1] http://marc.theaimsgroup.com/?l=linux-netdev&m=111446723510962&w=2
(This is one of a series of 3 patches - the others can't be
found in the archive. But they're all in 2.6.12-rc4.)
[2] http://marc.theaimsgroup.com/?l=linux-netdev&m=111567944730302&w=2
("tagged status" patch)
[3] http://marc.theaimsgroup.com/?l=linux-netdev&m=111586526522981&w=2
("hw coalescing infrastructure" patch)
The data I sent yesterday was also with 2.6.12-rc3 (I
mistakenly said it was rc2.) Also, I should have said
that I only used the default coalescence parameters
with [3] - didn't tune them with ethtool. Same is true
of today's data.
The graphs show that the tagged status patch ([2]) is
associated with fewer received packets/interrupt and
higher CPU utilization. I found that the reason is that,
under high receive load, most of the time (~80%) the
tag in the status block changes between the time that
it's read (and saved as last_tag) in tg3_poll(), and when
it's written back to MAILBOX_INTERRUPT_0 in
tg3_restart_ints(). If I understand the way the status
tag works, that means that the card will immediately
generate another interrupt. That's consistent with
what I'm seeing - a much higher interrupt rate when the
tagged status patch is used.
--
Arthur
[-- Attachment #2: CPU utilization --]
[-- Type: IMAGE/png, Size: 2991 bytes --]
[-- Attachment #3: Received Packets/Interrupt --]
[-- Type: IMAGE/png, Size: 2617 bytes --]
next prev parent reply other threads:[~2005-05-13 23:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-13 2:49 Perf data with recent tg3 patches Arthur Kepner
[not found] ` <20050512.211935.67881321.davem@davemloft.net>
2005-05-13 23:57 ` Arthur Kepner [this message]
2005-05-14 0:50 ` David S. Miller
2005-05-14 0:39 ` Michael Chan
2005-05-14 5:20 ` David S. Miller
2005-05-20 21:52 ` Arthur Kepner
2005-05-20 22:33 ` David S. Miller
2005-05-20 22:52 ` Rick Jones
2005-05-20 22:54 ` Arthur Kepner
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.0505131648140.14917@linux.site \
--to=akepner@sgi.com \
--cc=davem@davemloft.net \
--cc=mchan@broadcom.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).