Re: 2.5 or 2.4 kernel profiling

[Graham Stoney <greyham@research.canon.com.au>]

On Wed, Dec 13, 2000 at 11:14:00AM -0500, Dan Malek wrote:
> Although I have not yet proven this, I am leaning toward the following.
> Allocate a small fixed set of receive buffers (like we used to do)
> in the driver and mark them copy-back cached.  The received BDs will
> always point to thesed buffers.

I dunno; now that I've heard about the "buffer deficit scheme", I think it
gives better memory utilisation, since the receive buffers aren't permanently
tied up in the network driver.  It's the way the other drivers now do it.

> Then, copy-and-sum these into IP aligned skbuffs.

I think it depends whether the gain of having IP headers aligned outweighs the
cost of the extra copy in place of just a checksum.  The copy will tend to
throw more stuff out of the cache since it's dealing with the data twice.
Conventional logic when optimising network stacks is to eliminate copies, and
the only thing I see here that contradicts that is that we end up with not-
nicely-aligned IP headers.  In my application, eliminating the copy more than
offset the loss due to unaligned headers.

> The advantage of Graham's DMA into skbufs isn't that the driver doesn't
> copy/sum, it is that later when the IP stack does it we get burst transfers
> into cache.

But we get burst transfers into cache in either case, whether it's during
the checksum in csum_partial or the copy/sum in csum_partial_copy_generic.
The difference is that in the copy case, the data that gets loaded is only
used once, to write to another address in another cache line.  This extra
write will carry both a caching and bus penalty, and the impact is likely to
be worse in real applications than in simplistic throuhput tests.  Hence I
believe the conventional wisdom about eliminating the copy applies.

I know everything has second order effects and profiling is a perilous
minefield, but just occasionally things really do end up the way first order
thinking suggests :-).

Regards,
Graham
--
Graham Stoney
Assistant Technology Manager
Canon Information Systems Research Australia
Ph: +61 2 9805 2909  Fax: +61 2 9805 2929

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/