Template:Article summary heading Template:Article summary wiki - Linux-ck Changelog. Template:Article summary wiki - Setup and contents of unofficial repo-ck. Template:Article summary wiki - Util to keep track of all probed modules. Template:Article summary end
- 1 General Package Details
- 2 Installation Options
- 3 How to Enable the BFQ I/O Scheduler
- 4 Troubleshooting
- 5 A Little About the BFS
- 6 BFS Myths
- 7 Further Reading on BFS and CK Patchset
- 8 Linux-ck Package Changelog
General Package Details
AUR and in the unofficial linux-ck repo that allows users to run a kernel/headers setup patched with Con Kolivas' ck1 patchset, including the Brain Fuck Scheduler (BFS). Many Archers elect to use this package for the BFS' excellent desktop interactivity and responsiveness under any load situation.AUR is a package available in the
Linux-ck roughly follows the release cycle of upstream. The following are requirements for its release:
- Upstream code
- CK's Patchset
- BFQ Patchset
- ARCH config/config.x86_64 sets for major version jumps only
- There are two modifications to the config files:
- The options that the ck patchset enable/disable.
- The options that the BFQ patchset need to compile without user interaction.
All other options are set to the ARCH defaults outlined in the main kernel's config files. Users are of course free to modify them! The linux-ck package contains an option to switch on the nconfig config editor (see section below). For some suggestions, see CK's BFS configuration FAQ.
Users have two options to get these kernel packages.
1. Compile the Package From Source
The AUR contains entries for both packages mentioned above. Download and install as you would any other AUR package. AUR - current kernel in the 3.x.y series.
Users can customize the linux-ck package via tweaks in the PKGBUILD:
- Optional nconfig for user specific tweaking.
- Option to compile a minimal set of modules via a make localmodconfig.
- Option to bypass the standard ARCH config options and simply use the current kernel's .config file.
- Optionally set the BFQ I/O scheduler as default.
- Option to add the UKSM patchset to enable an alternative KSM.
More details about these options are provided in the PKGBUILD itself via line comments. Be sure to read them if compiling from the AUR!
2. Use Pre-Compiled Packages
If users would rather not spend the time to compile on their own, an unofficial repo maintained by graysky is available to the community.
For details, see: Repo-ck.
How to Enable the BFQ I/O Scheduler
Globally (for all devices)
If compiling from the AUR, simply set the BFQ flag to yes in the PKGBUILD prior to building.
If using the repo packages, append "elevator=bfq" to the kernel boot line in
/boot/grub/menu.lst if using grub or in
/etc/default/grub under the GRUB_CMDLINE_LINUX_DEFAULT="quiet" line followed by rebuilding
/boot/grub/grub.cfg via the standard "grub-mkconfig -o /boot/grub/grub.cfg" command.
Selectively (for only specified devices)
An alternative method is to direct the kernel to use it on a device-by-device basis. For example, to enable it for
# echo bfq > /sys/block/sda/queue/scheduler
To confirm, simply cat the same file:
# cat /sys/block/sda/queue/scheduler noop deadline cfq [bfq]
Note that doing it this way will not survive a reboot. To make the change automatically at the next system boot, place the echo line(s) in
Running Virtualbox with Linux-ck
Virtualbox works just fine with custom kernels such as Linux-ck without the need to keep any of the official ARCH kernel packages on the system (i.e. linux and linux-headers from [core]). The trick to keeping pacman from bringing down the ARCH kernel packages is to install virtualbox with the virtualbox-source package. Why? Wonder kindly responded to FS#26721.
# pacman -S virtualbox virtualbox-source
After pacman finishes, simply generate the kernel modules (for linux-ck) like this (assuming the system is booted into the linux-ck kernel):
Please use this discussion thread to voice comments, questions, suggestions, requests, etc. Note from graysky, "I can add other CPU-specific builds upon request. I just wanna be sure people will actually use them if I take the time to compile them."
A Little About the BFS
BFS Design Goals
The BFS has two major design goals:
- Achieve excellent desktop interactivity and responsiveness without heuristics and tuning knobs that are difficult to understand, impossible to model and predict the effect of, and when tuned to one workload cause massive detriment to another.
- Completely do away with the complex designs of the past for the cpu process scheduler and instead implement one that is very simple in basic design.
For additional information, see the linux-ck#Further_Reading_on_BFS_and_CK_Patchset section of this article.
An Example Video About Queuing Theory
See this video about queuing theory for an interesting parallel with supermarket checkouts. Quote from CK, "the relevance of that video is that BFS uses a single queue, whereas the mainline Linux kernel uses a multiple queue design. The people are tasks, and the checkouts are CPUs. Of course there's a lot more to a CPU scheduler than just the queue design, but I thought this video was very relevant."
Some Performance-Based Metrics: BFS vs. CFS
A major benefit of using the BFS is increased responsiveness. The benefits however, are not limited to desktop feel. Graysky put together some non-responsiveness based benchmarks to compare it to the CFS contained in the "stock" linux kernel. Recognize however, that it was not implicitly designed to provide superior performance. The purpose of the benchmarks was to evaluate the CPU scheduler in the stock Linux kernel against the BFS in the corresponding kernel patched with the ck1 patchset on different machines to see if differences exist and to what degree they scale using performance based metrics even though these end points were never within the scope of primary design goals of the BFS.
It is noteworthy to mention that this is not a novel idea, Phoronix also benchmarking using non-latency based endpoints about which Con subsequently blogged.
[Benchmark results] are available for download in pdf format.
For those not wanting to see the data and just wanting the highlights:
- 7 different machines ranging from 1 to 16 cores were benchmark using both a make and a x264-based video benchmark.
- Each machine ran both the "standard" linux kernel (linux-3.0.1-2 from [core]) and the ck1-patched version of this kernel (linux-ck-3.0.6-2 from graysky's unofficial repo).
- All 7 machines preformed better using the linux-ck package on the make benchmark.
- x264 encoding results were mixed. 4 machines performed better on the BFS scheduler; 1 gave same results; and 3 performed worse. It should be noted that an experimental version (svn) of handbrake was used for these tests.
BFS patched kernels CAN in fact use systemd
It is a common mistake to think that bfs does not support cgroups. It does support cgroups, just not all the cgroup features. Systemd works perfectly fine with BFS patched kernels.