BFS Scheduler Benchmarks

[RealNC]

I'll do my best
I mean there isn't any option in the kernel config which permits you to choose what scheduler you use?

Nope. The BFS patch completely removes CFS from the kernel.

[Apopas]

Assuming you know how to install the resulting kernel and editing /boot/grub/grub.conf to boot it :P

I'll do my best
I mean there isn't any option in the kernel config which permits you to choose what scheduler you use?

[RealNC]

Assuming you know how to install the resulting kernel and editing /boot/grub/grub.conf to boot it :P

[Apopas]

So the kernel is patched now? I just compile and the new kernel image will use the BFS scheduler automatically?

[RealNC]

You can ignore that error. It just tries to append an "-bfs240" to your kernel name. You can that yourself.

[vesa]

The patch applies to 2.6.31 kernel. If the kernel is already patched, you need to merge patches yourself... It seems you are one step forward on 2.6.31.1

[Apopas]

Well I'd suggest you to take a look at Makefile.rej and if you can't make any sense of it yourself pastebin it and post it here.

Here it is:

***************
*** 1,7 ****
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 31
- EXTRAVERSION =
NAME = Man-Eating Seals of Antiquity

# *DOCUMENTATION*
--- 1,7 ----
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 31
+ EXTRAVERSION = -bfs240
NAME = Man-Eating Seals of Antiquity

# *DOCUMENTATION*

[Zhick]

Back on topic

I tried to aply the BFS patch in 2.6.31.1 but I'm getting this:


Any idea what's going wrong?

Well I'd suggest you to take a look at Makefile.rej and if you can't make any sense of it yourself pastebin it and post it here.

[Apopas]

Back on topic

I tried to aply the BFS patch in 2.6.31.1 but I'm getting this:

gentoo linux-2.6.31-gentoo-r1 # patch -p1 < 2.6.31-sched-bfs-240.patch
patching file Documentation/sysctl/kernel.txt
patching file fs/pipe.c
patching file include/linux/init_task.h
patching file include/linux/sched.h
patching file kernel/sched.c
patching file kernel/sysctl.c
Hunk #3 succeeded at 259 (offset 18 lines).
Hunk #4 succeeded at 692 (offset 18 lines).
patching file kernel/workqueue.c
patching file kernel/sched_fair.c
patching file kernel/sched_idletask.c
patching file kernel/sched_rt.c
patching file kernel/sched_bfs.c
patching file kernel/Makefile
patching file kernel/kthread.c
patching file kernel/posix-cpu-timers.c
patching file kernel/exit.c
patching file kernel/fork.c
patching file mm/oom_kill.c
patching file init/Kconfig
patching file kernel/delayacct.c
patching file kernel/trace/trace.c
patching file fs/proc/base.c
patching file kernel/sched_debug.c
patching file include/linux/ioprio.h
patching file Makefile
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej
patching file kernel/Kconfig.preempt
patching file kernel/timer.c

Any idea what's going wrong?

[Apopas]

The claim that the kernel itself is 11Mloc and comparing it to NT's 10Mloc is comparing apples to grapefruits. NT's codebase is almost purely KERNEL code. Linux' codebase is nearly half drivers. Taking an aggressive position on bloat and using that comparison can look like FUD or Trolling and it's been a game of the people who DO that thing in the MS camp.

This is interesting. Can you back up your claims? If it is true that half of Linux 11 MloC is drivers, then it is not as bad as I thought. And NTs codebase of 10MloC is almost purely Kernel code? Can you back that up?

http://www.techworld.com.au/article/...er_code_climbs
It actually says that while for a while the amount of drivers in kernel code and the amount of everything else was 50-50, after 2.6.27 the drivers share became over 60% and from 2.6.30-2.6.31 specifically, it became 76% for drivers+firmware.
Now, if you combine the above link with that one http://www.theregister.co.uk/2009/08...opment_report/ which (including others) it says that kernel-2.6.11 had 6.6 millions of lines while kernel-2.6.30 had 11.6 millions, it's easy to understand the amount of millions of code that belongs exclusively to drivers.

Also, with kernel-2.6.31 Linux became the first OS which supports USB-3.0. Do you think this is a matter of a few dozens of lines? Now, if the adoption of the latest technology is considered a bloat, then I'd prefer to use the most bloated system ever.

Is it now as bad as you thought? (your words)
I just posted links as you do as well and one of the two was Torvalds' words.
But do you know what the weird thing is? I needed much more time to make this post rather than find the above links. So I'm sure you could find them as easy if you wanted. Maybe you just didn't intent to?

edited Very interesting link whowriteslinux.pdf
edited again 2.6.32-rc1 67% drivers and 10% firmware. Even higher than the previous one...
I hope to be abvious now that the vast amount of Linux kernel is consistent from drivers. Like this, I hope one day to catch the 30 millions of lines!

And for last time coz I was bored... 2.6.27
Programs like SLOCCount can be used to inspect the Linux kernel's source code in more detail. According to this tool, the source code line count is not 9 million but exactly 6,399,191 (Source Lines of Code/SLOC), as the program doesn't count blank lines, comments and several other types of input. More than half of the lines are part of hardware drivers; the second largest chunk is the arch/ directory which contains the source code of the various architectures supported by Linux.

So, if more than 50% of kernel-2.6.27 are drivers and after 2.6.27 the added drivers were over 60% and 76% and 77% for the last two releases, with combination that the latest kernels add more lines than the previous ones and with combination with the fact that the second largest part belongs to arch with the 50+ architectures which Linux supports, then I think we can say that drivers+arch consist more than 70% of Linux kernel!

I hope that's enough!