lkml.org 
[lkml]   [2002]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Lse-tech] Re: (RFC): SKB Initialization

Mala Anand wrote:
>
> Baseline 2.5.25
> ----------------
> alloc/free average cycles
> -------------------------
> Runs: 1st 2nd 3rd
>
> CPU0: 337/1163 336/1132 304/1100
> CPU1: 318/1164 309/1153 311/1127
>
> 2.5.25+skbinit patch
> --------------------
>
> alloc/free average cycles
> -------------------------
> Runs: 1st 2nd 3rd
>
> CPU0: 447/1015 580/846 402/905
> CPU1: 419/1003 383/915 547/856
>
> The above figures indicate that the cycles spent in alloc_skb and
> __kfree_skb have gained 5% in the patch case. However if you
> take the absolute cycles and average them for the three runs it
> comes around 145 cycles saving that is close to what I posted earlier
> by measuring just the changed code. As the scope of the code measured
> widens the percentage improvement comes down.

Measuring just the initialization code yielded a reduction of 156 cycles.
Measuring alloc_skb and __kfree_skb yielded a reduction of 145 cycles.
This was on a 2 CPU system.

The worst case scenario would be allocating the skb header on one
CPU then freeing it on another CPU. The best case would be doing
all of the allocs and frees on one CPU.

You can use process/irq affinity to create both of these cases.
Can you measure these ?

Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.078 / U:1.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site