BORE CPU Scheduler Testing

ReillyBrogan

Hello all! This sync has brought the 6.5.5 kernel with an additional improvement by the Solus team. We've implemented the BORE CPU scheduler into our kernel but have disabled it by default. The BORE CPU scheduler is a modification of the default CFS scheduler but optimized for interactive desktops. It is designed so that under heavy CPU load the system will try to prioritize processes that it thinks are interactive, this should help keep your desktops responsive when you are doing something tasking on the system. We intend to enable this by default in a future update, but for now it's opt-in only.

If you would like to give this a try you can follow the below instructions to enable it.

Requirements:

Must be on a fully updated Solus system
Must be using the linux-current kernel (sorry linux-lts users, this will not be coming to you until your kernel is updated to a newer major version)
Though no major issues came up in our testing we cannot guarantee that that will be the case across ALL hardware. You therefor must be willing to take the risk that you may need to switch to a TTY or perform boot rescue in order to get a usable system (though we consider that scenario very unlikely).
All of the steps to enable this are provided as CLI steps, so you must be comfortable using the command line.

Not scared away yet? Okay let's get this enabled:

Make sure your system is running at least kernel 6.5.5-258

sudo uname -r

The BORE scheduler is enabled and disabled by sysctls. You can enable it for the current boot only by running the following command:

sudo sysctl -w kernel.sched_bore=1

Boom it's enabled! This change will not be persisted if you reboot or shutoff, but this is perfect for making sure your system won't explode or anything when it's enabled.

You can test it by just manually enabling it every boot, but I reckon you might want to make sure it's enabled on every boot automatically. That's easy:

sudo mkdir -p /etc/sysctl.d
echo "kernel.sched_bore=1" | sudo tee /etc/sysctl.d/85-bore.conf

And then reboot. It should be active when you log in. You can verify this by running:

sysctl kernel.sched_bore

If you get the following then it's enabled and working!

kernel.sched_bore = 1

If you would like to disable it on future boots you can do the following to delete the sysctl that we just created:

sudo rm /etc/sysctl.d/85-bore.conf

Note that it will still be enabled by default once we make it the default configuration.

Please direct any issues or feedback you have on this to this Solus package issue

davidjharder

Been running this for a while now, can report: completely boring

penny-farthing

In a topic entitled "BORE CPU Scheduler Testing", I noticed a difference in the commands proposed by @ReillyBrogan in his post to activate it permanently and those mentioned in the GitHub (it seems important to me to report it).

Indeed, @ReillyBrogan indicates the following command:

echo "kernel.sched_bore=1" | sudo tee /etc/sysctl.d/85-bore.conf

while GitHub indicates this one:

echo "kernel.sched_bore=1" | sudo tee /etc/sysctl.d/80-bore.conf

the difference being in the file name.

As far as I'm concerned, having Solus Budgie at my disposal, I applied the GitHub commands (since I was in the link) following the recommended procedure and all went well.
But I must say that I didn't notice any significant difference.

Does the file name matter in this development?

Finally, I wrote this post this way because I couldn't reply to the original post and didn't know how else to communicate. I hope I haven't done anything wrong, but if I have, please excuse me.

ReillyBrogan

penny-farthing Sorry, we didn't realize that permissions on discussion with the development tag were so restricted. I WAS wondering why nobody seemed to be commenting or reacting to this post, but I just took it as something that people weren't interested in.

I've fixed the permissions now, so everyone can comment and react to their heart's liking.

Regarding your question, no it doesn't really matter. sysctl.d files are processed in order of their file name, something with 10-foo.conf will be processed before 20-bar.conf, which means that if there are conflicting settings then the one in 20-bar.conf will override the one in 10-foo.conf. Since you probably don't have the bore settings in any of your other sysctl.d files it doesn't really matter (if you even have any other sysctl.d files).

nolan

AFAIK, the number in the file name, makes reference to the priority of that file being loaded, I'm not sure how.
for example: 1 is greater priority than 2. or am I mistaken?

Solarmass

I think the number is not important for the current testing of this feature, but I am not sure if it would be true when the feature will be enabled by default for everyone i.e. what would be the final file name 🤔

penny-farthing

ReillyBrogan

Thank you for these clarifications.

Axios

No issues seems to make things alittle more responsive (snappy) on this low 2g ram system.
I know it doesnt effect ram.

bleh

Nothing to report here either, overall makes the tasks on my pc smoother

ender

On an old laptop, it was quite tedious to browse internet while running demanding tasks such as compiling stuff. This setting noticeably improved the responsiveness the desktop

Sebastian

After turning this on, on an old HP Elite Book 6930p running Gnome, I had 2 or 3 times, probably under high cpu load, an error message popping up that process xy (I think it was software center and rednotebook) wasn't responding and if I wanted to wait or kill the process. Can't remember having seen this before. Though I wasn't able to reproduce and don't know if it is related to bore cpu scheduler.

ReillyBrogan

Sebastian Solarmass

Well, try disabling it and see if it gets better. I don't know that BORE really offers much in the way of diagnostics messages when it's doing something incorrectly. To disable it just delete the sysctl.d file and reboot.

Solarmass

I wonder should this setting affect music playing somehow? I had some stuttering today/yesterday, but not sure if it's related to BORE CPU scheduler 🤷

ReillyBrogan

Oh, I think this was mentioned in a sync notes thread but this has been enabled by default. In the event that you don't want this for whatever reason you can disable it by setting the sysctl flags to 0 instead.

sudo sysctl -w kernel.sched_bore=0

Or permanently:

sudo mkdir -p /etc/sysctl.d
echo "kernel.sched_bore=0" | sudo tee /etc/sysctl.d/85-bore.conf

If you still have the sysctl conf file from when you manually enabled it you can now just delete that, no point in keeping it around.

sudo rm /etc/sysctl.d/85-bore.conf

Thanks everyone for helping test it!

lf-araujo

I am leaving this here in case someone come across this issue too. So if you have a laptop with two GPUs (integrated + NVIDIA) the BORE scheduler will cause lag in the interface in softwares you try to offload to the NVIDIA graphics card. In my case Brave browser and Zoom. Disabling this solved the issue. I will try the scheduler in the future to check whether this persists in later updates.