| To: | Eric Dumazet <dada1@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [PATCH] loop unrolling in net/sched/sch_generic.c |
| From: | Thomas Graf <tgraf@xxxxxxx> |
| Date: | Tue, 5 Jul 2005 14:03:27 +0200 |
| Cc: | "David S. Miller" <davem@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx |
| In-reply-to: | <20050705115108.GE16076@postel.suug.ch> |
| References: | <20050704.154712.63128211.davem@davemloft.net> <42C9BE69.2070008@cosmosbay.com> <42C9BEF6.4080402@cosmosbay.com> <20050704.160140.21591849.davem@davemloft.net> <42CA390C.9000801@cosmosbay.com> <20050705115108.GE16076@postel.suug.ch> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
* Thomas Graf <20050705115108.GE16076@xxxxxxxxxxxxxx> 2005-07-05 13:51 > * Eric Dumazet <42CA390C.9000801@xxxxxxxxxxxxx> 2005-07-05 09:38 > > [NET] : unroll a small loop in pfifo_fast_dequeue(). Compiler generates > > better code. > > (Using skb_queue_empty() to test the queue is faster than trying to > > __skb_dequeue()) > > oprofile says this function uses now 0.29% instead of 1.22 %, on a > > x86_64 target. > > I think this patch is pretty much pointless. __skb_dequeue() and > !skb_queue_empty() should produce almost the same code and as soon > as you disable profiling and debugging you'll see that the compiler > unrolls the loop itself if possible. ... given one enables it of course. |
| Previous by Date: | Re: [PATCH] loop unrolling in net/sched/sch_generic.c, Thomas Graf |
|---|---|
| Next by Date: | Re: [PATCH] loop unrolling in net/sched/sch_generic.c, Eric Dumazet |
| Previous by Thread: | Re: [PATCH] loop unrolling in net/sched/sch_generic.c, Thomas Graf |
| Next by Thread: | Re: [PATCH] loop unrolling in net/sched/sch_generic.c, Eric Dumazet |
| Indexes: | [Date] [Thread] [Top] [All Lists] |