Re: [Lse-tech] Re: (RFC): SKB Initialization

[Dave Hansen <haveblue@us.ibm.com>]

Mala Anand wrote:
> Readprofile ticks are not as accurate as the cycles I measured.
> Moreover readprofile can give misleading information as it profiles
> on timer interrupts. The alloc_skb and __kfree_skb call memory
> management routines and interrupts are disabled in many parts of that code.
> So I don't trust the readprofile data.

I don't believe your results to be accurate.  They may be _precise_ 
for a small case, but you couldn't have been measuring them for very 
long.  A claim of accuracy requires a large number of samples, which 
you apparently did not do.

I can't use oprofile or other NMI-based profilers on my hardware, so 
we'll just have to guess.  Is there any chance that you have access to 
a large Specweb setup on hardware that is close to mine and can run 
oprofile?

Where are interrupts disabled?   I just went through a set of kernprof 
data and traced up the call graph.  In the most common __kfree_skb 
case, I do not believe that it has interupts disabled.  I could be 
wrong, but I didn't see it.

http://www.sr71.net/~specweb99/old/run-specweb-2300-nodynpost-2.5.31-bk+profilers-08-14-2002-02.19.22/callgraph

The end result, as I can see it, is that your patches hurt Specweb 
performance.  They moved the profile around, but there was an overall 
decline in performance.  They partly address the symptom, but not the 
real problem.  We don't need to _tune_ it, we need to fix it.

The e1000's need to allocate/free fewer skbs.  NAPI's polling mode 
_should_ help this, or at least make it possible to batch them up.
-- 
Dave Hansen
haveblue@us.ibm.com