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
cpu_vs_link.3.png
Description: CPU utilization
packets_vs_link.3.png
Description: Received Packets/Interrupt
|
