From ArchWiki
Jump to navigation Jump to search

BFQ Scheduler auto loading

Inspired by a forumpost i recommend to ad the following text and script to the Wiki at the end of section 2.2.5:

When using more than one kernel at the same system, you can use the following script in /etc/rc.local This will automitically load the BFQ Scheduler only when kernel26-ck is loaded. The BFQ status will be written to a logfile.

#Enable BFQ for precompiled kernel26-ck from the unofficial repository
TID=$(date +%c)
KERN=$(uname -r | cut -d"-" -f2)
if [ "$KERN" == 'ck' ]; then
modprobe bfq-iosched
echo bfq > /sys/block/sda/queue/scheduler
echo "$TID $(uname -r) with $KERN patch so started bfq for sda" >> /var/log/bfq.log
echo "$TID $(uname -r) no bfq loaded" >> /var/log/bfq.log
Thanks for the suggestion. I modified the linux-ck package to actually compile in the BFQ (just not enabled by default). Once CK and Paolo get release their respective patches for 3.0.1, I'll update the repo and the wiki page. Thanks for the re-direct btw! Graysky 17:12, 8 August 2011 (EDT)
It seems like BFQ was not compiled into linux-ck-core2 3.0.1-3 ("zcat /proc/config.gz | grep BFQ" shows nothing, and I'm running the -ck kernel).Jimreynold2nd 14:44, 15 August 2011 (EDT)
Right, that's because BFQ for 3.0 does not yet exist. Paolo hasn't released the code for the 3.0 series :) I will update as soon as he does. Graysky 04:32, 16 August 2011 (EDT)

Enabling BFQ selectively section

This section should be updated: you say to put the "echo bfq" command in rc.local...there is no more support for it, and there is: 1)the systemd-way -> tmpfiles 2)the udev-rule way.

May be you should report both, or choose what do you think is the best, i trust you!

Thanks for your time (i preferred to open discussion rather than change it myself, did i the right thing?)

New section 2.2.3: rerun grub-mkconfig

After the installation subsection, I would suggest adding a new subsection to remind folks to rerun grub-mkconfig (or the appropriate boot reconfig command for their bootloader) and reboot, so they will be able to see the new kernel and CPU scheduler in action right away. They will have to do this whether or not they want to enable bfq, as I just found out from a kind soul on the Arch Linux Google+ group.

This step may be obvious to old hands, but as an Arch newb whose system was frequently maxing out, I needed to try BFS and bfq as soon as possible. I'm still getting used to generating a grub config file myself instead of having the installer do it for me...!

Should there be a BFQ section with MuQSS?

I've noticed that it's recommended that one enables BFQ, shouldn't this be removed in place of MuQSS?

—This unsigned comment is by X89 (talk) 11:01, 4 August 2017‎. Please sign your posts with ~~~~!

ck patchset for linux-4.15 (Unofficial)

This is a merge that I did unofficially to get the ck patchset onto 4.15. So I manually merged the last official patchset from 4.14, made a few minor additions required, some minor changes here and therem etc. There are no additional features or anything here, just a merge forward. I did not do extensive research on all of the recent kernel development work, and I haven't done significant kernel devleopment in years, but I believe everything provided here to be correct. It has been running now stable for me for 36 hours. No lockups, no glitches or lnong hangs, so it seems like everything scheduling-wise is working as intended, which is the core of the patchset and where all the changes I had to make went. Full disclosure: I did get 2 panics one time from ethernet driver (e1000) even though I'm not plugged into anything, but it was just like a tx receive error, didn't cause any noticable issue, and was more likely some artifact of the suspend of the parent OS (I am running linux on virtualbox on top of windows 10 for warrenty reasons on new laptop). I do not expect you to have any issues either.


Oh yeah, you can find the patches and README and such here:

—This unsigned comment is by Barbariccow (talk) 01:07, 4 February 2018‎. Please sign your posts with ~~~~!

While I applause your efforts to help port the ck patchset, announcing uncited and unconfirmed rumors as pretext is not cool. CK himself replied to me in a private email: "Yeah bullshit. It'll probably be a week or so though. CK" Graysky (talk) 11:23, 4 February 2018 (UTC)
I specifically noted in the text that I did not know if they were true or not. I do not see what the big issue is with this; maybe if I said "Con Kolivas is no longer doing patchsets" there would be an issue, but I did not say this. I said that I had read unconfirmed rumors, which was part of the impetus behind me doing the merge myself and making it available. I appreciate you taking the time to confirm that these rumors were NOT true, but I also feel like you oculd have approached it with more tact, such as stating "I have confirmed with Con that he is not discontinuing work on the -ck patchset, and will have an official release out in about a weeks time." I'm not trying to start an issue or start drama, just pointing out that we should be friendly and kind towards one another, practicing Right Speech wherever possible. Thank you again for taking the time out of your day to confirm that the officials will still be rolling in -- this is certainly good news! Barbariccow (talk) 05:14, 8 February 2018 (UTC)

Is `linux-lts-ck` gone for good?

Or, paraphrased, is there a LTS version of linux-ck maintained for a current 5.10 LTS? I can see only a broken link to the previous AUR package, 4.xx one.

—This unsigned comment is by Thaewrapt (talk) 09:08, 6 May 2021‎. Please sign your posts with ~~~~!

Is `linux-ck` gone for good?

According to his blog, -ck is no longer maintained as of Aug 30, 2021 ... —This unsigned comment is by Bronze (talk) 16:13, 11 September 2021 (UTC). Please sign your posts with ~~~~!