netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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).