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.

41. 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 14:22 The patch must be changed to use __qdisc_dequeue_head() instead of __skb_dequeue() or we screw up the backlog.; /archives/netdev/2005-07/msg00279.html (10,702 bytes)
42. 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/msg00280.html (10,775 bytes)
43. 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 <20050705.142210.14973612.davem@xxxxxxxxxxxxx> 2005-07-05 14:22 So I'll apply the original unrolling patch for now. The patch must be changed to use __qdisc_dequeue_head() instead; /archives/netdev/2005-07/msg00281.html (13,448 bytes)
44. 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/msg00282.html (12,381 bytes)
45. 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/msg00283.html (11,042 bytes)
46. 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 16:45 Absolutely. I think what happens is that we produce predicion failures due to the logic within qdisc_dequeue_head(),; /archives/netdev/2005-07/msg00284.html (11,925 bytes)
47. 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 and; /archives/netdev/2005-07/msg00285.html (13,661 bytes)
48. 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/msg00286.html (12,023 bytes)
49. 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_head; /archives/netdev/2005-07/msg00287.html (14,343 bytes)
50. 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/msg00288.html (11,562 bytes)
51. 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 the; /archives/netdev/2005-07/msg00289.html (12,244 bytes)
52. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Wed, 6 Jul 2005 03:07:56 +0200; * Eric Dumazet <42CB2E24.6010303@xxxxxxxxxxxxx> 2005-07-06 03:04 Ahh... sorry, I misread your patch, interesting idea. I'll be waiting for your numbers.; /archives/netdev/2005-07/msg00290.html (12,036 bytes)
53. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Eric Dumazet <dada1@xxxxxxxxxxxxx>; Date: Wed, 06 Jul 2005 03:09:00 +0200; Thomas Graf a écrit : 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 queue in prio 0 is not empty. if prio 0 is; /archives/netdev/2005-07/msg00291.html (12,431 bytes)
54. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Wed, 6 Jul 2005 14:42:06 +0200; * Eric Dumazet <42CB2B84.50702@xxxxxxxxxxxxx> 2005-07-06 02:53 A short recap after some coffee and sleep: The inital issue you brought up which you backed up with numbers is probably the cause of mul; /archives/netdev/2005-07/msg00295.html (13,814 bytes)
55. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Thu, 07 Jul 2005 14:17:18 -0700 (PDT); As an aside, this reminds me that as part of my quest to make sk_buff smaller, I intend to walk across the tree and change all tests of the form: if (!skb_queue_len(list)) into: if (skb_queue_empty(l; /archives/netdev/2005-07/msg00308.html (11,776 bytes)
56. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Thu, 7 Jul 2005 23:34:50 +0200; * David S. Miller <20050707.141718.85410359.davem@xxxxxxxxxxxxx> 2005-07-07 14:17 Since I'm changing the classful qdiscs to use a generic API for queue management anyway I could take care of this if; /archives/netdev/2005-07/msg00309.html (11,489 bytes)
57. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Thu, 07 Jul 2005 15:24:17 -0700 (PDT); Ok. I'm going to check something like the following into my tree. It takes care of the obvious cases of direct binary test of queue length being zero vs. non-zero. This uncovered some seriously quest; /archives/netdev/2005-07/msg00312.html (47,575 bytes)
58. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Thu, 07 Jul 2005 15:30:37 -0700 (PDT); It does already.; /archives/netdev/2005-07/msg00314.html (7,621 bytes)
59. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Fri, 08 Jul 2005 00:30:14 -0700 (PDT); Distributions enable all of the ifdefs, and that is thus the size and resultant performance most users see. That's why I'm working on shrinking the size assuming all the config options are enabled, b; /archives/netdev/2005-07/msg00335.html (13,653 bytes)
60. Re: [PATCH] loop unrolling in net/sched/sch_generic.c (score: 1): Author: Eric Dumazet <dada1@xxxxxxxxxxxxx>; Date: Fri, 08 Jul 2005 10:19:46 +0200; About making sk_buff smaller, I use this patch to declare 'struct sec_path *sp' only ifdef CONFIG_XFRM, what do you think ? I also use a patch to declare nfcache, nfctinfo and nfct only if CONFIG_NE; /archives/netdev/2005-07/msg00336.html (12,084 bytes)

Current List: 41 - 60
Page: [1] [2] [3] [4]