Benchmarking Ubuntu's Low-Latency Kernel & Liquorix Post-Meltdown

[AndyChow]

These days, noop is probably the best scheduler, if you're seeking overall performance. SSDs have all sorts of internal algorithms which we know nothing about. noop just serves it and lets the hardware decide. Yes, if you're interested in "smooth" performance, you can try to mess things up with another scheduler, but if you're a cli, emacs type of person, go noop all the way. FIFO and let the hardware do it's magic.

[Licaon]

Until BFQ crashes or hard-locks their system and watch them crawl back to CFQ or Deadline.

Link? I'm not saying it's not possible but it helps to have actual issues reported.

[Rallos Zek]

Damn son, what is this, XDA?

I'll just say BFQ beats Deadline by a long shot when under moderate/heavy I/O, and it's only going to get better.

Until BFQ crashes or hard-locks their system and watch them crawl back to CFQ or Deadline.

[geearf]

For the first 2, if you get cpupower already autostarted, you can do it all in its config file, which to me seems cleaner, as that way you easily know what to look for in a year or 10 when you want to change things.

[Linuxxx]

Neat, with systemd services. I like that.

For kernels that have BFQ compiled in (not as a module) like most decent ones after 4.12, elevator=bfq does not work. The scsi_mod.use_blk_mq=1 is still required as a kernel commandline.
You must create a udev config file like for example 20-block.rules in /etc/udev/rules.d with the below in it and it will set BFQ as default during boot.

ACTION=="add|change", SUBSYSTEM=="block", ATTR{queue/scheduler}="bfq"

https://bfq.teambelgium.net/

Just tried to activate BFQ "my way" with GRUB on openSUSE Tumbleweed with Linux Kernel 4.14.

Output of dmesg | grep scheduler:

[    2.081113] io scheduler noop registered
[    2.081114] io scheduler deadline registered
[    2.081126] io scheduler cfq registered
[    2.081127] io scheduler mq-deadline registered
[    2.081127] io scheduler kyber registered
[    2.081135] io scheduler bfq registered (default)

So yeah, seems to work...

BTW, in my very limited testing of BFQ so far, things look quite promising!
It's just that I thought blk-mq wasn't ready yet...

[starshipeleven]

Neat, with systemd services. I like that.

For BFQ, you need to add as well:

scsi_mod.use_blk_mq=1 elevator=bfq

You're welcome!

For kernels that have BFQ compiled in (not as a module) like most decent ones after 4.12, elevator=bfq does not work. The scsi_mod.use_blk_mq=1 is still required as a kernel commandline.
You must create a udev config file like for example 20-block.rules in /etc/udev/rules.d with the below in it and it will set BFQ as default during boot.

ACTION=="add|change", SUBSYSTEM=="block", ATTR{queue/scheduler}="bfq"

https://bfq.teambelgium.net/

[ext73]

Performance governor:

cat << EOF | sudo tee /etc/systemd/system/performance.service
[Unit]
Description=CPU performance

[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower -c all frequency-set -g performance

[Install]
WantedBy=multi-user.target
EOF

Damaged by Intel users only:

cat << EOF | sudo tee /etc/systemd/system/bias.service
[Unit]
Description=CPU bias

[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower -c all set --perf-bias 0

[Install]
WantedBy=multi-user.target
EOF

After that:

sudo systemctl enable performance.service

sudo systemctl enable bias.service

Now reboot!

For deadline IO scheduler, add this to your GRUB Kernel command line:

elevator=deadline

For BFQ, you need to add as well:

scsi_mod.use_blk_mq=1 elevator=bfq

You're welcome!

but ... You can do it much simplest and better and ... both clock 250 and 1000 are not such perfect solutions

[Linuxxx]

How exactly do you do the above?

Performance governor:

cat << EOF | sudo tee /etc/systemd/system/performance.service
[Unit]
Description=CPU performance

[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower -c all frequency-set -g performance

[Install]
WantedBy=multi-user.target
EOF

Damaged by Intel users only:

cat << EOF | sudo tee /etc/systemd/system/bias.service
[Unit]
Description=CPU bias

[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower -c all set --perf-bias 0

[Install]
WantedBy=multi-user.target
EOF

After that:

sudo systemctl enable performance.service

sudo systemctl enable bias.service

Now reboot!

For deadline IO scheduler, add this to your GRUB Kernel command line:

elevator=deadline

For BFQ, you need to add as well:

scsi_mod.use_blk_mq=1 elevator=bfq

You're welcome!

[Linuxxx]

using the performance governor is handy for some use cases, mainly since you'll avoid CPU scaling... but using it all the time seems like bad advice... especially on any device where you care about power-saving or temperatures ....

and FYI, any desktop or mobile linux kernel is mostly going to be preempt. pretty standard stuff.

No need to worry, CPUs will still enter C-States!
Case in point: Even a passively cooled Notebook remains cool under normal usage.

Also, about this all being pretty standard stuff:
Go ahead and tell that to Red Hat (Fedora), Debian & Ubuntu!

[HenryM]

Spectre/Meltdown appear to (mostly) not affect games.

Or were you talking about Liquorix and kernel latency in general?

I mean in general. it would be very useful to compare a variety of AMD and Nvidia GPUs, driver and kernel combos, Linux vs Windows etc. and actual, effective latency, say, put a laser pointer on a mouse, measure mouse movement vs in-game monitor response with a high-speed camera...

I found some results here: https://docs.google.com/spreadsheets...E-w/edit#gid=0

some examples: GTX 970 averages 34ms (23-47ms), HD5770 was worse at about 47ms (36-56ms). both on an ASUS VG248QE monitor at 120Hz and Intel G4560 CPU.


I guess this is all a bit off-topic, but the generic vs low-latency vs Liquorix comparisons got me going.