Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+loop\s+unrolling\s+in\s+net\/sched\/sch

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+loop\s+unrolling\s+in\s+net\/sched\/sch_generic\.c\s*$/: 62 ]

Total 62 documents matching your query.

1. [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Eric Dumazet <dada1@xxxxxxxxxxxxx>; Date: Tue, 05 Jul 2005 09:38:52 +0200; [NET] : unroll a small loop in pfifo_fast_dequeue(). Compiler generates better (Using skb_queue_empty() to test the queue is faster than trying to __skb_dequeue()) oprofile says this function uses no; /archives/netdev/2005-07/msg00043.html (11,480 bytes)
2. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Tue, 5 Jul 2005 13:51:08 +0200; * Eric Dumazet <42CA390C.9000801@xxxxxxxxxxxxx> 2005-07-05 09:38 I think this patch is pretty much pointless. __skb_dequeue() and !skb_queue_empty() should produce almost the same code and as soon as; /archives/netdev/2005-07/msg00044.html (10,911 bytes)
3. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Tue, 5 Jul 2005 14:03:27 +0200; * Thomas Graf <20050705115108.GE16076@xxxxxxxxxxxxxx> 2005-07-05 13:51 ... given one enables it of course.; /archives/netdev/2005-07/msg00045.html (11,367 bytes)
4. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Eric Dumazet <dada1@xxxxxxxxxxxxx>; Date: Tue, 05 Jul 2005 15:04:21 +0200; Thomas Graf a écrit : * 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(); /archives/netdev/2005-07/msg00046.html (15,511 bytes)
5. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Tue, 5 Jul 2005 15:48:05 +0200; * Eric Dumazet <42CA8555.9050607@xxxxxxxxxxxxx> 2005-07-05 15:04 Because you don't specify -funroll-loop [...] Unrolled version: pfifo_fast_dequeue: pushl %esi xorl %edx, %edx pushl %ebx movl 12(%esp; /archives/netdev/2005-07/msg00047.html (14,324 bytes)
6. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Eric Dumazet <dada1@xxxxxxxxxxxxx>; Date: Tue, 05 Jul 2005 17:58:39 +0200; Thomas Graf a écrit : OK. At least my compiler (gcc-3.3.1) does NOT unroll the loop : Because you don't specify -funroll-loop I'm using vanilla 2.6.12 : no -funroll-loop in it. Maybe in your tree,; /archives/netdev/2005-07/msg00049.html (17,635 bytes)
7. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Tue, 5 Jul 2005 19:34:11 +0200; * Eric Dumazet <42CAAE2F.5070807@xxxxxxxxxxxxx> 2005-07-05 17:58 Do as you wish, I don't feel like argueing about micro optimizations.; /archives/netdev/2005-07/msg00051.html (11,409 bytes)
8. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Tue, 05 Jul 2005 14:22:10 -0700 (PDT); I bet the performance gain really comes from the mispredicted branches in the loop. For loops of fixed duration, say, 5 or 6 iterations or less, it totally defeats the branch prediction logic in most; /archives/netdev/2005-07/msg00053.html (10,887 bytes)
9. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Tue, 05 Jul 2005 14:26:41 -0700 (PDT); Eric, I've told you this before many times. Please do something so that your email client does not corrupt the patches. Once again, your email client turned all the tab characters into spaces and thu; /archives/netdev/2005-07/msg00054.html (10,525 bytes)
10. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Tue, 5 Jul 2005 23:33:55 +0200; * David S. Miller <20050705.142210.14973612.davem@xxxxxxxxxxxxx> 2005-07-05 The patch must be changed to use __qdisc_dequeue_head() instead of __skb_dequeue() or we screw up the backlog.; /archives/netdev/2005-07/msg00055.html (10,542 bytes)
11. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Tue, 05 Jul 2005 14:35:48 -0700 (PDT); Ok, good thing the patch didn't apply correctly anyways :); /archives/netdev/2005-07/msg00056.html (10,647 bytes)
12. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Eric Dumazet <dada1@xxxxxxxxxxxxx>; Date: Wed, 06 Jul 2005 01:16:02 +0200; David S. Miller a écrit : From: Thomas Graf <tgraf@xxxxxxx> Date: Tue, 5 Jul 2005 23:33:55 +0200 * David S. Miller <20050705.142210.14973612.davem@xxxxxxxxxxxxx> 2005-07-05 14:22 So I'll apply the; /archives/netdev/2005-07/msg00057.html (13,388 bytes)
13. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Wed, 6 Jul 2005 01:41:04 +0200; * Eric Dumazet <42CB14B2.5090601@xxxxxxxxxxxxx> 2005-07-06 01:16 Ok, this clarifies a lot for me, I was under the impression you knew about these changes. It is very unlikely to change within mainlin; /archives/netdev/2005-07/msg00058.html (12,197 bytes)
14. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Tue, 05 Jul 2005 16:45:03 -0700 (PDT); But the branch prediction is where I personally think a lot of the lossage is coming from. These can cost upwards of 20 or 30 processor cycles, easily. That's getting close to the cost of a L2 cache; /archives/netdev/2005-07/msg00059.html (10,920 bytes)
15. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Wed, 6 Jul 2005 01:55:04 +0200; * David S. Miller <20050705.164503.104035718.davem@xxxxxxxxxxxxx> 2005-07-05 Absolutely. I think what happens is that we produce predicion failures due to the logic within qdisc_dequeue_head(), I can; /archives/netdev/2005-07/msg00060.html (11,755 bytes)
16. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Eric Dumazet <dada1@xxxxxxxxxxxxx>; Date: Wed, 06 Jul 2005 02:32:24 +0200; Thomas Graf a écrit : I still think we can fix this performance issue without manually unrolling the loop or we should at least try to. In the end gcc should notice the constant part of the loop an; /archives/netdev/2005-07/msg00061.html (13,636 bytes)
17. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Wed, 6 Jul 2005 02:51:40 +0200; * Eric Dumazet <42CB2698.2080904@xxxxxxxxxxxxx> 2005-07-06 02:32 Correct. The !expr implies an unlikely so the prediction should be right and equal to your unrolling version. This would break the who; /archives/netdev/2005-07/msg00062.html (11,785 bytes)
18. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Eric Dumazet <dada1@xxxxxxxxxxxxx>; Date: Wed, 06 Jul 2005 02:53:24 +0200; Eric Dumazet a écrit : Maybe we can rewrite the whole thing without branches, examining prio from PFIFO_FAST_BANDS-1 down to 0, at least for modern cpu with conditional mov (cmov) struct sk_buff_he; /archives/netdev/2005-07/msg00063.html (14,337 bytes)
19. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Wed, 6 Jul 2005 03:02:00 +0200; * Eric Dumazet <42CB2B84.50702@xxxxxxxxxxxxx> 2005-07-06 02:53 I think you got me wrong, the whole point of this qdisc is to prioritize which means that we cannot dequeue from prio 1 as long as the q; /archives/netdev/2005-07/msg00064.html (11,304 bytes)
20. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Eric Dumazet <dada1@xxxxxxxxxxxxx>; Date: Wed, 06 Jul 2005 03:04:36 +0200; Thomas Graf a écrit : Maybe we can rewrite the whole thing without branches, examining prio from PFIFO_FAST_BANDS-1 down to 0, at least for modern cpu with conditional mov (cmov) This would break t; /archives/netdev/2005-07/msg00065.html (12,078 bytes)

Current List: 1 - 20
Page: [1] [2] [3] [4]