netdev
[Top] [All Lists]

Re: Perf data with recent tg3 patches

To: "David S.Miller" <davem@xxxxxxxxxxxxx>
Subject: Re: Perf data with recent tg3 patches
From: Arthur Kepner <akepner@xxxxxxx>
Date: Fri, 13 May 2005 16:57:51 -0700 (PDT)
Cc: mchan@xxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20050512.211935.67881321.davem@xxxxxxxxxxxxx>
References: <Pine.LNX.4.61.0505121942190.14917@xxxxxxxxxx> <20050512.211935.67881321.davem@xxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
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: cpu_vs_link.3.png
Description: CPU utilization

Attachment: packets_vs_link.3.png
Description: Received Packets/Interrupt

<Prev in Thread] Current Thread [Next in Thread>