2.6.32.5-vanila vs 2.6.32-ck2

pyther · 2010-01-25 19:44:17

I decided to benchmark kernel 2.6.32-vanilla against 2.6.32-ck2

I used the phoronix test suite and ran the multicore suite.

Here are my results: http://pyther.net/benchmarks/multicore/composite.xml

Most of the test were near identical with the exception of:
7-Zip Compression - vanilla was the clear winner
Sunflow Rendering System - ck2 was 4 seconds faster.

Kernel suite: http://pyther.net/benchmarks/kernel/composite.xml
Dbench - was notably faster with the vanilla kernel

Last edited by pyther (2010-01-26 02:38:41)

sand_man · 2010-01-26 22:30:16

How is -ck different to -bfs?

pyther · 2010-01-26 23:46:14

The ck patchset includes bfs and then additional patches.
List of patches here: http://www.kernel.org/pub/linux/kernel/ … 2/patches/

pyther · 2010-01-27 01:30:59

Interesting...

Openoffice-base-devel compile:
CK: 2hrs 23 Minutes 17 Seconds
Vanilla: 2hrs 18 Minutes 45 Seconds

lustikus · 2010-01-27 15:09:03

I've always been suspicious to treating the -ck kernel as the reinvention of the wheel.
please keep posting your results.

MP2E · 2010-01-28 04:42:02

Wow this is very interesting. I've only been using the kernel26-ck kernel myself (As I am the maintainer in the AUR, hehe). Keep it up

fsckd · 2010-01-28 05:09:55

The bfs patch exists to improve responsiveness, not speed things up. Perhaps the other ck patches are like this?

eldragon · 2010-01-28 13:08:48

fsckd wrote:

The bfs patch exists to improve responsiveness, not speed things up. Perhaps the other ck patches are like this?

exactly, even if its not as fast. the desktop feels snappier. not to mention i can watch full screen you tuve videos without much trouble. this is not the case with CFS. this is the only reason i keep patching my kernel. one day cfs might evolve and solve this. till then. bfs ftw!

sHyLoCk · 2010-01-28 13:22:28

Even I found it snappier using -ck. Anyway I'm also interested in the benchmarks. Please carry on the good work!

mcsaba77 · 2010-01-28 13:53:43

Doesn't the -ck patchset improve interactivity for general desktop usage? I mean I would never expect it be faster at long running tasks. I mean does the comparison make sense when the goal is interactivity? And finally, which tests are relevant when we want to measure interactivity and/or perceived snappyness?

I don't mean to criticise the test, these are truly open-ended questions... I'm just merely curious.

nous · 2010-02-08 17:30:54

Please, remember that the bfs scheduler's intention is to make things more fluid and responsive. To achieve this it must and has to sacrifice a small percent of absolute performance. In fact, I was surprised to see it performing that close to cfs. As I've written in another bfs thread, I had experienced unacceptable skips with cfs in audio/video applications whenever the hard disk thrashed, which were gone and forgotten with bfs (even the 'deadline' scheduler was better than cfs).

A good read on why cfs is crap: http://www.mattheaton.com/?p=222

Renan Birck · 2010-02-08 18:09:01

Since we're talking about CK, is anybody using the higher HZ options (> 1000)? I would like to try them, but I'm afraid of drivers breaking and/or data loss/hardware damage.

fsckd · 2010-02-08 18:13:49

nous wrote:

A good read on why cfs is crap: http://www.mattheaton.com/?p=222

I wonder what he thinks of BFS. I found this to be interesting: It may be a good design for a desktop, and admittedly the kernel guys have made low latency desktops a priority but still… Consider, ck's complaint was the exact opposite in that the kernel devs do not care about real world desktop performance.

flamelab · 2010-02-08 18:56:13

The -CK kernel is the best for single/dual core machines, where the desktop responsiveness and speed scales up higher. On a Quad-core machine, you won't find much difference.

nous · 2010-02-08 23:12:25

fsckd wrote:

nous wrote:
A good read on why cfs is crap: http://www.mattheaton.com/?p=222
I wonder what he thinks of BFS. I found this to be interesting: It may be a good design for a desktop, and admittedly the kernel guys have made low latency desktops a priority but still… Consider, ck's complaint was the exact opposite in that the kernel devs do not care about real world desktop performance.

I don't regularly read the LKML, but from snippets I've read here and there I think it was after the release of bfs and the following publicity that the kernel scheduler guys initially posted instructions on how to make cfs more desktop-oriented and finally tweaked cfs to more low-latency defaults. Here's a quote from mingo in early September, just after the first benchmarks showed that bfs reigned supreme:

Note that you can tune the basic kernel latency goals/deadlines via two dynamic sysctls: sched_wakeup_granularity_ns and sched_latency_ns. Lower those and you'll get a snappier desktop - at the expense of some throughput.
You can set these in /etc/sysctl.conf to make the settings permanent. (and please report it to us if a new setting improves some workload in a dramatic way - we constantly re-tune the upstream default as well, to make for a snappier desktop.)

(from http://lwn.net/Articles/351359/)

Another great feature of bfs is its strict adherence to nice levels. Now, I 'nice -n 20 make -j2' and the kernel tree compiles totally unnoticed.

1LordAnubis · 2010-02-08 23:54:40

Renan Birck wrote:

Since we're talking about CK, is anybody using the higher HZ options (> 1000)? I would like to try them, but I'm afraid of drivers breaking and/or data loss/hardware damage.

The reason I stay away from HZ>1000 is the first time I tried the -ck kernel, I used 1500 hz and wasn't able to build the virtualbox module. I'm not sure, but I think the virtualbox module must be a multiple of 1000 hz.

timong · 2010-02-26 16:43:01

yeah, interesting. Anyone with bad enough CPU to test responsiveness based on these values:

http://marc.info/?l=linux-kernel&m=125261747323052&w=2

It would be nice to see if using these values with CFS vs. BFS, how responsiveness equals out, or not.

Last edited by timong (2010-02-26 16:43:28)

stargeizer · 2010-04-30 05:49:14

Guys... probably you're missing something: "Responsiveness" in the desktop is not something you can really measure with numbers or timings...

The best way to test is to have 2 machines, with the same hardware, ram, processor, etc. and do a side by side test. This is the best way to verify what scheduler has the best responsiveness...

My 2 cents.

Regards.

J.

Arch Linux

#1 2010-01-25 19:44:17

2.6.32.5-vanila vs 2.6.32-ck2

#2 2010-01-26 22:30:16

Re: 2.6.32.5-vanila vs 2.6.32-ck2

#3 2010-01-26 23:46:14

Re: 2.6.32.5-vanila vs 2.6.32-ck2

#4 2010-01-27 01:30:59

Re: 2.6.32.5-vanila vs 2.6.32-ck2

#5 2010-01-27 15:09:03

Re: 2.6.32.5-vanila vs 2.6.32-ck2

#6 2010-01-28 04:42:02

Re: 2.6.32.5-vanila vs 2.6.32-ck2

#7 2010-01-28 05:09:55

Re: 2.6.32.5-vanila vs 2.6.32-ck2

#8 2010-01-28 13:08:48

Re: 2.6.32.5-vanila vs 2.6.32-ck2

#9 2010-01-28 13:22:28

Re: 2.6.32.5-vanila vs 2.6.32-ck2

#10 2010-01-28 13:53:43

Re: 2.6.32.5-vanila vs 2.6.32-ck2

#11 2010-02-08 17:30:54

Re: 2.6.32.5-vanila vs 2.6.32-ck2

#12 2010-02-08 18:09:01

Re: 2.6.32.5-vanila vs 2.6.32-ck2

#13 2010-02-08 18:13:49

Re: 2.6.32.5-vanila vs 2.6.32-ck2

#14 2010-02-08 18:56:13

Re: 2.6.32.5-vanila vs 2.6.32-ck2

#15 2010-02-08 23:12:25

Re: 2.6.32.5-vanila vs 2.6.32-ck2

#16 2010-02-08 23:54:40

Re: 2.6.32.5-vanila vs 2.6.32-ck2

#17 2010-02-26 16:43:01

Re: 2.6.32.5-vanila vs 2.6.32-ck2

#18 2010-04-30 05:49:14

Re: 2.6.32.5-vanila vs 2.6.32-ck2

Board footer