* tbench regression on each kernel release from 2.6.22 -> 2.6.28 @ 2008-08-11 18:36 Christoph Lameter 2008-08-11 18:50 ` Kok, Auke ` (2 more replies) 0 siblings, 3 replies; 19+ messages in thread From: Christoph Lameter @ 2008-08-11 18:36 UTC (permalink / raw) To: netdev; +Cc: lkml It seems that the network stack becomes slower over time? Here is a list of tbench results with various kernel versions: 2.6.22 3207.77 mb/sec 2.6.24 3185.66 2.6.25 2848.83 2.6.26 2706.09 2.6.27(rc2) 2571.03 And linux-next is: 2.6.28(l-next) 2568.74 It shows that there is still have work to be done on linux-next. Too close to upstream in performance. Note the KT event between 2.6.24 and 2.6.25. Why is that? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: tbench regression on each kernel release from 2.6.22 -> 2.6.28 2008-08-11 18:36 tbench regression on each kernel release from 2.6.22 -> 2.6.28 Christoph Lameter @ 2008-08-11 18:50 ` Kok, Auke 2008-08-11 18:56 ` Christoph Lameter 2008-08-11 21:15 ` David Miller 2008-08-18 1:48 ` Zhang, Yanmin 2 siblings, 1 reply; 19+ messages in thread From: Kok, Auke @ 2008-08-11 18:50 UTC (permalink / raw) To: Christoph Lameter; +Cc: netdev, lkml Christoph Lameter wrote: > It seems that the network stack becomes slower over time? Here is a list of > tbench results with various kernel versions: > > 2.6.22 3207.77 mb/sec > 2.6.24 3185.66 > 2.6.25 2848.83 > 2.6.26 2706.09 > 2.6.27(rc2) 2571.03 > > And linux-next is: > > 2.6.28(l-next) 2568.74 > > It shows that there is still have work to be done on linux-next. Too close to > upstream in performance. > > Note the KT event between 2.6.24 and 2.6.25. Why is that? is this with SLAB or with SLUB? SLUB has been known to impact network performance... Auke ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: tbench regression on each kernel release from 2.6.22 -> 2.6.28 2008-08-11 18:50 ` Kok, Auke @ 2008-08-11 18:56 ` Christoph Lameter 0 siblings, 0 replies; 19+ messages in thread From: Christoph Lameter @ 2008-08-11 18:56 UTC (permalink / raw) To: Kok, Auke; +Cc: netdev, lkml Kok, Auke wrote: > is this with SLAB or with SLUB? SLUB has been known to impact network performance... The original testing config was SLAB based so it was used throughout. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: tbench regression on each kernel release from 2.6.22 -> 2.6.28 2008-08-11 18:36 tbench regression on each kernel release from 2.6.22 -> 2.6.28 Christoph Lameter 2008-08-11 18:50 ` Kok, Auke @ 2008-08-11 21:15 ` David Miller 2008-08-11 21:33 ` Christoph Lameter 2008-08-12 8:13 ` Ilpo Järvinen 2008-08-18 1:48 ` Zhang, Yanmin 2 siblings, 2 replies; 19+ messages in thread From: David Miller @ 2008-08-11 21:15 UTC (permalink / raw) To: cl; +Cc: netdev, linux-kernel From: Christoph Lameter <cl@linux-foundation.org> Date: Mon, 11 Aug 2008 13:36:38 -0500 > It seems that the network stack becomes slower over time? Here is a list of > tbench results with various kernel versions: > > 2.6.22 3207.77 mb/sec > 2.6.24 3185.66 > 2.6.25 2848.83 > 2.6.26 2706.09 > 2.6.27(rc2) 2571.03 > > And linux-next is: > > 2.6.28(l-next) 2568.74 > > It shows that there is still have work to be done on linux-next. Too close to > upstream in performance. > > Note the KT event between 2.6.24 and 2.6.25. Why is that? Isn't that when some major scheduler changes went in? I'm not blaming the scheduler, but rather I'm making the point that there are other subsystems in the kernel that the networking interacts with that influences performance at such a low level. This includes the memory allocator :-) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: tbench regression on each kernel release from 2.6.22 -> 2.6.28 2008-08-11 21:15 ` David Miller @ 2008-08-11 21:33 ` Christoph Lameter 2008-08-11 21:50 ` David Miller 2008-08-12 7:11 ` Andi Kleen 2008-08-12 8:13 ` Ilpo Järvinen 1 sibling, 2 replies; 19+ messages in thread From: Christoph Lameter @ 2008-08-11 21:33 UTC (permalink / raw) To: David Miller; +Cc: netdev, linux-kernel David Miller wrote: > Isn't that when some major scheduler changes went in? I'm not blaming > the scheduler, but rather I'm making the point that there are other > subsystems in the kernel that the networking interacts with that > influences performance at such a low level. This includes the memory > allocator :-) Right this covers a significant portion of the kernel. SLAB was used since .22 was pretty early for SLUB. And around 2.6.24 we had the merges of the antifrag logic. .25 was the point where HR timers came in. By switching off hrtimers I can get some (minor) portion of performance back. There must be more things in play though. Maybe what we are seeing is general bloat in kernel execution paths due to the growth in complexity? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: tbench regression on each kernel release from 2.6.22 -> 2.6.28 2008-08-11 21:33 ` Christoph Lameter @ 2008-08-11 21:50 ` David Miller 2008-08-11 21:56 ` Kok, Auke 2008-08-12 7:11 ` Andi Kleen 1 sibling, 1 reply; 19+ messages in thread From: David Miller @ 2008-08-11 21:50 UTC (permalink / raw) To: cl; +Cc: netdev, linux-kernel From: Christoph Lameter <cl@linux-foundation.org> Date: Mon, 11 Aug 2008 16:33:43 -0500 > Maybe what we are seeing is general bloat in kernel execution paths > due to the growth in complexity? It could be, and any kind of analysis into this would be great. I had a change that RCU destroyed sockets and this added a tiny bit of latency, so I never added it even though it would have allowed a lot of simplification of socket handling (which I though would make up for RCU's latency, but it didn't). ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: tbench regression on each kernel release from 2.6.22 -> 2.6.28 2008-08-11 21:50 ` David Miller @ 2008-08-11 21:56 ` Kok, Auke 2008-08-11 22:11 ` Rick Jones 0 siblings, 1 reply; 19+ messages in thread From: Kok, Auke @ 2008-08-11 21:56 UTC (permalink / raw) To: David Miller; +Cc: cl, netdev, linux-kernel, Rick Jones David Miller wrote: > From: Christoph Lameter <cl@linux-foundation.org> > Date: Mon, 11 Aug 2008 16:33:43 -0500 > >> Maybe what we are seeing is general bloat in kernel execution paths >> due to the growth in complexity? > > It could be, and any kind of analysis into this would be great. perhaps Rick Jones who maintains netperf could enlighten us on some historic numbers? he usually seems to be happy to prop up new netperf numbers :) Auke ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: tbench regression on each kernel release from 2.6.22 -> 2.6.28 2008-08-11 21:56 ` Kok, Auke @ 2008-08-11 22:11 ` Rick Jones 0 siblings, 0 replies; 19+ messages in thread From: Rick Jones @ 2008-08-11 22:11 UTC (permalink / raw) To: Kok, Auke; +Cc: David Miller, cl, netdev, linux-kernel Kok, Auke wrote: > David Miller wrote: > >>From: Christoph Lameter <cl@linux-foundation.org> >>Date: Mon, 11 Aug 2008 16:33:43 -0500 >> >> >>>Maybe what we are seeing is general bloat in kernel execution paths >>>due to the growth in complexity? >> >>It could be, and any kind of analysis into this would be great. > > > perhaps Rick Jones who maintains netperf could enlighten us on some historic > numbers? he usually seems to be happy to prop up new netperf numbers :) While this is an excellent opening to talk about how netperf top-of-trunk can now emit keyword=value results easier (ostensibly) to put into a database then the regular or even CSV output formats, I cannot fully exploit it by pointing at a database of results :( rick jones ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: tbench regression on each kernel release from 2.6.22 -> 2.6.28 2008-08-11 21:33 ` Christoph Lameter 2008-08-11 21:50 ` David Miller @ 2008-08-12 7:11 ` Andi Kleen 2008-08-12 18:57 ` Christoph Lameter 1 sibling, 1 reply; 19+ messages in thread From: Andi Kleen @ 2008-08-12 7:11 UTC (permalink / raw) To: Christoph Lameter; +Cc: David Miller, netdev, linux-kernel Christoph Lameter <cl@linux-foundation.org> writes: > Maybe what we are seeing is general bloat in kernel execution paths > due to the growth in complexity? Wouldn't surprise me. Have you considered doing profiles? e.g. just oprofiling the benchmark on the different kernels and see if there's some obvious difference in the CPU consumers? -Andi ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: tbench regression on each kernel release from 2.6.22 -> 2.6.28 2008-08-12 7:11 ` Andi Kleen @ 2008-08-12 18:57 ` Christoph Lameter 0 siblings, 0 replies; 19+ messages in thread From: Christoph Lameter @ 2008-08-12 18:57 UTC (permalink / raw) To: Andi Kleen; +Cc: David Miller, netdev, linux-kernel Andi Kleen wrote: > Christoph Lameter <cl@linux-foundation.org> writes: > >> Maybe what we are seeing is general bloat in kernel execution paths >> due to the growth in complexity? > > Wouldn't surprise me. Have you considered doing profiles? If I get the time I will try to do that. Another way to understand why we are accepting the regressions here may be that we give more consideration to real time issues and deterministic performance these days. Hardware speed gains compensate for the additional bloat? (I ran the old kernels on cutting edge hardware after all). ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: tbench regression on each kernel release from 2.6.22 -> 2.6.28 2008-08-11 21:15 ` David Miller 2008-08-11 21:33 ` Christoph Lameter @ 2008-08-12 8:13 ` Ilpo Järvinen 2008-08-18 2:05 ` Zhang, Yanmin 1 sibling, 1 reply; 19+ messages in thread From: Ilpo Järvinen @ 2008-08-12 8:13 UTC (permalink / raw) To: David Miller; +Cc: cl, Netdev, LKML On Mon, 11 Aug 2008, David Miller wrote: > From: Christoph Lameter <cl@linux-foundation.org> > Date: Mon, 11 Aug 2008 13:36:38 -0500 > > > It seems that the network stack becomes slower over time? Here is a list of > > tbench results with various kernel versions: > > > > 2.6.22 3207.77 mb/sec > > 2.6.24 3185.66 > > 2.6.25 2848.83 > > 2.6.26 2706.09 > > 2.6.27(rc2) 2571.03 > > > > And linux-next is: > > > > 2.6.28(l-next) 2568.74 > > > > It shows that there is still have work to be done on linux-next. Too close to > > upstream in performance. > > > > Note the KT event between 2.6.24 and 2.6.25. Why is that? > > Isn't that when some major scheduler changes went in? I'm not blaming > the scheduler, but rather I'm making the point that there are other > subsystems in the kernel that the networking interacts with that > influences performance at such a low level. ...IIRC, somebody in the past did even bisect his (probably netperf) 2.6.24-25 regression to some scheduler change (obviously it might or might not be related to this case of yours)... -- i. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: tbench regression on each kernel release from 2.6.22 -> 2.6.28 2008-08-12 8:13 ` Ilpo Järvinen @ 2008-08-18 2:05 ` Zhang, Yanmin 2008-08-18 7:53 ` Ilpo Järvinen 2008-08-18 14:07 ` Christoph Lameter 0 siblings, 2 replies; 19+ messages in thread From: Zhang, Yanmin @ 2008-08-18 2:05 UTC (permalink / raw) To: Ilpo Järvinen; +Cc: David Miller, cl, Netdev, LKML On Tue, 2008-08-12 at 11:13 +0300, Ilpo Järvinen wrote: > On Mon, 11 Aug 2008, David Miller wrote: > > > From: Christoph Lameter <cl@linux-foundation.org> > > Date: Mon, 11 Aug 2008 13:36:38 -0500 > > > > > It seems that the network stack becomes slower over time? Here is a list of > > > tbench results with various kernel versions: > > > > > > 2.6.22 3207.77 mb/sec > > > 2.6.24 3185.66 > > > 2.6.25 2848.83 > > > 2.6.26 2706.09 > > > 2.6.27(rc2) 2571.03 > > > > > > And linux-next is: > > > > > > 2.6.28(l-next) 2568.74 > > > > > > It shows that there is still have work to be done on linux-next. Too close to > > > upstream in performance. > > > > > > Note the KT event between 2.6.24 and 2.6.25. Why is that? > > > > Isn't that when some major scheduler changes went in? I'm not blaming > > the scheduler, but rather I'm making the point that there are other > > subsystems in the kernel that the networking interacts with that > > influences performance at such a low level. > > ...IIRC, somebody in the past did even bisect his (probably netperf) > 2.6.24-25 regression to some scheduler change (obviously it might or might > not be related to this case of yours)... I did find much regression with netperf TCP-RR-1/UDP-RR-1/UDP-RR-512. I start 1 serve and 1 client while binding them to a different logical processor in different physical cpu. Comparing with 2.6.22, the regression of TCP-RR-1 on 16-core tigerton is: 2.6.23 6% 2.6.24 6% 2.6.25 9.7% 2.6.26 14.5% 2.6.27-rc1 22% Other regressions on other machines are similar. yanmin ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: tbench regression on each kernel release from 2.6.22 -> 2.6.28 2008-08-18 2:05 ` Zhang, Yanmin @ 2008-08-18 7:53 ` Ilpo Järvinen 2008-08-19 0:56 ` Zhang, Yanmin 2008-08-18 14:07 ` Christoph Lameter 1 sibling, 1 reply; 19+ messages in thread From: Ilpo Järvinen @ 2008-08-18 7:53 UTC (permalink / raw) To: Zhang, Yanmin; +Cc: David Miller, cl, Netdev, LKML [-- Attachment #1: Type: TEXT/PLAIN, Size: 2118 bytes --] On Mon, 18 Aug 2008, Zhang, Yanmin wrote: > > On Tue, 2008-08-12 at 11:13 +0300, Ilpo Järvinen wrote: > > On Mon, 11 Aug 2008, David Miller wrote: > > > > > From: Christoph Lameter <cl@linux-foundation.org> > > > Date: Mon, 11 Aug 2008 13:36:38 -0500 > > > > > > > It seems that the network stack becomes slower over time? Here is a list of > > > > tbench results with various kernel versions: > > > > > > > > 2.6.22 3207.77 mb/sec > > > > 2.6.24 3185.66 > > > > 2.6.25 2848.83 > > > > 2.6.26 2706.09 > > > > 2.6.27(rc2) 2571.03 > > > > > > > > And linux-next is: > > > > > > > > 2.6.28(l-next) 2568.74 > > > > > > > > It shows that there is still have work to be done on linux-next. Too close to > > > > upstream in performance. > > > > > > > > Note the KT event between 2.6.24 and 2.6.25. Why is that? > > > > > > Isn't that when some major scheduler changes went in? I'm not blaming > > > the scheduler, but rather I'm making the point that there are other > > > subsystems in the kernel that the networking interacts with that > > > influences performance at such a low level. > > > > ...IIRC, somebody in the past did even bisect his (probably netperf) > > 2.6.24-25 regression to some scheduler change (obviously it might or might > > not be related to this case of yours)... > I did find much regression with netperf TCP-RR-1/UDP-RR-1/UDP-RR-512. I start > 1 serve and 1 client while binding them to a different logical processor in > different physical cpu. > > Comparing with 2.6.22, the regression of TCP-RR-1 on 16-core tigerton is: > 2.6.23 6% > 2.6.24 6% > 2.6.25 9.7% > 2.6.26 14.5% > 2.6.27-rc1 22% > > Other regressions on other machines are similar. I btw reorganized tcp_sock for 2.6.26, it shouldn't cause this but it's not always obvious what even a small change in field ordering does for performance (it's b79eeeb9e48457579cb742cd02e162fcd673c4a3 in case you want to check that). Also, there was this 83f36f3f35f4f83fa346bfff58a5deabc78370e5 fix to current -rcs but I guess it might not be that significant in your case (but I don't know well enough :-)). -- i. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: tbench regression on each kernel release from 2.6.22 -> 2.6.28 2008-08-18 7:53 ` Ilpo Järvinen @ 2008-08-19 0:56 ` Zhang, Yanmin 0 siblings, 0 replies; 19+ messages in thread From: Zhang, Yanmin @ 2008-08-19 0:56 UTC (permalink / raw) To: Ilpo Järvinen; +Cc: David Miller, cl, Netdev, LKML On Mon, 2008-08-18 at 10:53 +0300, Ilpo Järvinen wrote: > On Mon, 18 Aug 2008, Zhang, Yanmin wrote: > > > > > On Tue, 2008-08-12 at 11:13 +0300, Ilpo Järvinen wrote: > > > On Mon, 11 Aug 2008, David Miller wrote: > > > > > > > From: Christoph Lameter <cl@linux-foundation.org> > > > > Date: Mon, 11 Aug 2008 13:36:38 -0500 > > > > > > > > > It seems that the network stack becomes slower over time? Here is a list of > > > > > tbench results with various kernel versions: > > > > > > > > > > 2.6.22 3207.77 mb/sec > > > > > 2.6.24 3185.66 > > > > > 2.6.25 2848.83 > > > > > 2.6.26 2706.09 > > > > > 2.6.27(rc2) 2571.03 > > > > > > > > > > And linux-next is: > > > > > > > > > > 2.6.28(l-next) 2568.74 > > > > > > > > > > It shows that there is still have work to be done on linux-next. Too close to > > > > > upstream in performance. > > > > > > > > > > Note the KT event between 2.6.24 and 2.6.25. Why is that? > > > > > > > > Isn't that when some major scheduler changes went in? I'm not blaming > > > > the scheduler, but rather I'm making the point that there are other > > > > subsystems in the kernel that the networking interacts with that > > > > influences performance at such a low level. > > > > > > ...IIRC, somebody in the past did even bisect his (probably netperf) > > > 2.6.24-25 regression to some scheduler change (obviously it might or might > > > not be related to this case of yours)... > > I did find much regression with netperf TCP-RR-1/UDP-RR-1/UDP-RR-512. I start > > 1 serve and 1 client while binding them to a different logical processor in > > different physical cpu. > > > > Comparing with 2.6.22, the regression of TCP-RR-1 on 16-core tigerton is: > > 2.6.23 6% > > 2.6.24 6% > > 2.6.25 9.7% > > 2.6.26 14.5% > > 2.6.27-rc1 22% > > > > Other regressions on other machines are similar. > > I btw reorganized tcp_sock for 2.6.26, it shouldn't cause this but it's > not always obvious what even a small change in field ordering does for > performance (it's b79eeeb9e48457579cb742cd02e162fcd673c4a3 in case you > want to check that). > > Also, there was this 83f36f3f35f4f83fa346bfff58a5deabc78370e5 fix to > current -rcs but I guess it might not be that significant in your case > (but I don't know well enough :-)). I reverted the patch against 2.6.27-rc1 and did a quick testing with netperf TCP-RR-1 and didn't find improvement. So your patch is good. Mostly, I suspect process scheduler causes the regression. It seems when there are only 1 or 2 tasks running on the cpu, the performance isn't good. My netperf testing is just one example. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: tbench regression on each kernel release from 2.6.22 -> 2.6.28 2008-08-18 2:05 ` Zhang, Yanmin 2008-08-18 7:53 ` Ilpo Järvinen @ 2008-08-18 14:07 ` Christoph Lameter 2008-08-18 14:31 ` Ray Lee 2008-08-19 1:01 ` Zhang, Yanmin 1 sibling, 2 replies; 19+ messages in thread From: Christoph Lameter @ 2008-08-18 14:07 UTC (permalink / raw) To: Zhang, Yanmin; +Cc: Ilpo Järvinen, David Miller, Netdev, LKML Zhang, Yanmin wrote: > Other regressions on other machines are similar. There are AIM7 regressions that are similar to tbench. 2.6.22 28436 2.6.26 23064 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: tbench regression on each kernel release from 2.6.22 -> 2.6.28 2008-08-18 14:07 ` Christoph Lameter @ 2008-08-18 14:31 ` Ray Lee 2008-08-18 14:34 ` Christoph Lameter 2008-08-19 1:01 ` Zhang, Yanmin 1 sibling, 1 reply; 19+ messages in thread From: Ray Lee @ 2008-08-18 14:31 UTC (permalink / raw) To: Christoph Lameter Cc: Zhang, Yanmin, Ilpo Järvinen, David Miller, Netdev, LKML On Mon, Aug 18, 2008 at 7:07 AM, Christoph Lameter <cl@linux-foundation.org> wrote: > Zhang, Yanmin wrote: > >> Other regressions on other machines are similar. > > There are AIM7 regressions that are similar to tbench. > > 2.6.22 28436 > 2.6.26 23064 Just a shot in the dark -- is this with Group Scheduling on or off? Off is prefered for benchmarks. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: tbench regression on each kernel release from 2.6.22 -> 2.6.28 2008-08-18 14:31 ` Ray Lee @ 2008-08-18 14:34 ` Christoph Lameter 0 siblings, 0 replies; 19+ messages in thread From: Christoph Lameter @ 2008-08-18 14:34 UTC (permalink / raw) To: Ray Lee; +Cc: Zhang, Yanmin, Ilpo Järvinen, David Miller, Netdev, LKML Ray Lee wrote: > On Mon, Aug 18, 2008 at 7:07 AM, Christoph Lameter > <cl@linux-foundation.org> wrote: >> Zhang, Yanmin wrote: >> >>> Other regressions on other machines are similar. >> There are AIM7 regressions that are similar to tbench. >> >> 2.6.22 28436 >> 2.6.26 23064 > > Just a shot in the dark -- is this with Group Scheduling on or off? > Off is prefered for benchmarks. Off ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: tbench regression on each kernel release from 2.6.22 -> 2.6.28 2008-08-18 14:07 ` Christoph Lameter 2008-08-18 14:31 ` Ray Lee @ 2008-08-19 1:01 ` Zhang, Yanmin 1 sibling, 0 replies; 19+ messages in thread From: Zhang, Yanmin @ 2008-08-19 1:01 UTC (permalink / raw) To: Christoph Lameter; +Cc: Ilpo Järvinen, David Miller, Netdev, LKML On Mon, 2008-08-18 at 09:07 -0500, Christoph Lameter wrote: > Zhang, Yanmin wrote: > > > Other regressions on other machines are similar. > > There are AIM7 regressions that are similar to tbench. > > 2.6.22 28436 > 2.6.26 23064 Mostly, AIM7 has about 4~5% regression on my machines. As AIM7 result is stable, so 4% is big. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: tbench regression on each kernel release from 2.6.22 -> 2.6.28 2008-08-11 18:36 tbench regression on each kernel release from 2.6.22 -> 2.6.28 Christoph Lameter 2008-08-11 18:50 ` Kok, Auke 2008-08-11 21:15 ` David Miller @ 2008-08-18 1:48 ` Zhang, Yanmin 2 siblings, 0 replies; 19+ messages in thread From: Zhang, Yanmin @ 2008-08-18 1:48 UTC (permalink / raw) To: Christoph Lameter; +Cc: netdev, lkml On Mon, 2008-08-11 at 13:36 -0500, Christoph Lameter wrote: > It seems that the network stack becomes slower over time? Here is a list of > tbench results with various kernel versions: > > 2.6.22 3207.77 mb/sec > 2.6.24 3185.66 > 2.6.25 2848.83 > 2.6.26 2706.09 > 2.6.27(rc2) 2571.03 What's the hardware configuration? Is it dual-core? I also track tbench performance with lastest kernels on a couple of quad-core machines, and didn't find such regression while the results did have fluctuation. What's the commandline you is using to start tbench? I start tbench with CPU_NUM*2. BTW, I enabled CONFIG_SLUB since 2.6.22. > > And linux-next is: > > 2.6.28(l-next) 2568.74 > > It shows that there is still have work to be done on linux-next. Too close to > upstream in performance. > > Note the KT event between 2.6.24 and 2.6.25. Why is that? ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2008-08-19 1:03 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-08-11 18:36 tbench regression on each kernel release from 2.6.22 -> 2.6.28 Christoph Lameter 2008-08-11 18:50 ` Kok, Auke 2008-08-11 18:56 ` Christoph Lameter 2008-08-11 21:15 ` David Miller 2008-08-11 21:33 ` Christoph Lameter 2008-08-11 21:50 ` David Miller 2008-08-11 21:56 ` Kok, Auke 2008-08-11 22:11 ` Rick Jones 2008-08-12 7:11 ` Andi Kleen 2008-08-12 18:57 ` Christoph Lameter 2008-08-12 8:13 ` Ilpo Järvinen 2008-08-18 2:05 ` Zhang, Yanmin 2008-08-18 7:53 ` Ilpo Järvinen 2008-08-19 0:56 ` Zhang, Yanmin 2008-08-18 14:07 ` Christoph Lameter 2008-08-18 14:31 ` Ray Lee 2008-08-18 14:34 ` Christoph Lameter 2008-08-19 1:01 ` Zhang, Yanmin 2008-08-18 1:48 ` Zhang, Yanmin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).