Arch Linux User Repository

@Filip98, I'll re-enable hierarchical scheduling once Paolo corrects an oops when it's enabled. You can see the progress on the bfq-iosched google group here: https://groups.google.com/forum/#!topic/bfq-iosched/5wkrbgXf4VM

This kernel seems to have an issue with libvirt(Qemu/KVM) http://i64.tinypic.com/30m9ul3.jpg http://i65.tinypic.com/oqg1ow.jpg I've digged a little bit around the net: https://forums.whonix.org/t/solved-cant-start-the-new-14-whonix-vms-libvirterror-unsupported-configuration-block-i-o-tuning-is-not-available-on-this-host/5664 and looks like it requires the following to be enabled in the kernel: CONFIG_BLK_CGROUP CONFIG_CFQ_GROUP_IOSCHED CONFIG_BLK_DEV_THROTTLING I switched to my alternative kernel and it runs fine, I didn't recompile to confirm that this fixes the issue tho

@Terence, I briefly experimented again with 1000hz but it was a huge drain on battery life. MuQSS 0.173 (and possibly 0.180 with 4.19), doesn't support tickless idle correctly, and ends up feeding cpufreq with bad idle data. The periodic forces cpufreq to ingest idle time accounting data, letting the cpu properly rest while idle, but the periodic tick prevents the CPU from staying in the CPU's lowest state (C6 / C7). It's measurable, and I mentioned some data points in my commit reverting back to 250hz here:

https://github.com/damentz/liquorix-package/commit/070398c973863e03dc384e578e27f58d9f05c607

Until I figure out a better compromise with 1000hz, you'll need to manually go in on every build and raise the frequency to 1000hz for your system. It's perfectly fine for desktops but a huge problem on laptops. Both my personal and work laptops lose about 20%-30% battery life for idle / casual loads. In my testing, 250hz preserves cpu temperatures as well as tickless idle, so that'll work for now.

Also, I re-enabled IRQ time accounting as it seems that it was originally added so that the process scheduler (CFS in this case), had more accurate data about how much cpu time each task consumed. It should have some benefits for MuQSS as well.

@sir_lucjan, ok, thanks!

@Agafron

I don't think so.

https://github.com/damentz/liquorix-package/commit/51704fbc01fd69274ce2c236fa2d180276d6aa60

https://github.com/damentz/liquorix-package/commit/7dd11beb3448cb3bca3b175566022d96bb35db46

@sir_lucjan, ok, need I reinstall package?

$ uname -r

4.18.19-lqx1-1-lqx

Agafron:

No.

https://github.com/damentz/liquorix-package/commit/7dd11beb3448cb3bca3b175566022d96bb35db46

@damentz, I have some diff of versions:

1 aur/linux-lqx 4.18.19_2-2 [installed: 4.18.20_1-1] (114) (1,86)

A desktop oriented kernel and modules with Liquorix patches

2 aur/linux-lqx-docs 4.18.19_2-2 [installed: 4.18.20_1-1] (114) (1,86)

Kernel hackers manual - HTML documentation that comes with the linux-lqx.

3 aur/linux-lqx-headers 4.18.19_2-2 [installed: 4.18.20_1-1] (114) (1,86)

Its PKGBUILD mistake?

@Terence, that's good information. While you were comparing results, I was measuring the overhead of 1000hz vs 250hz.

With 250hz, the timer consumes about 2-3ms, every second. Increasing this to 1000hz almost quadruples it. At idle, the timer tick consumes 8ms/s, but 5ms/s when the system is under full load (highest frequency). 8ms is less than 1% of the cpu usage of one core on a processor.

On the flip-side, one change I made with switching to 250hz is to re-instate a sampling down factor on ondemand. While the system is idle, it consumes about 3-5ms/s worth of processing to determine the next frequency. While the system is under full load, or near full load, ondemand consumes less than 1ms/s.

One thing I was wondering if you could try is adding rqshare=mc to your kernel parameters. Liquorix is currently configured with smt runqueue sharing, which improves throughput by looking for tasks in the order of cache locality. This might be influencing your underruns in a bad way.

@damentz I tried your suggestion but it didn't seem to improve things. I have between 3 and 4 times less xruns when using 1000Hz tick rate compared to the now default 250Hz. My test settings were a sample rate of 48000 Hz with 64 as the buffer size giving a latency of 1.3ms. I used the performance governor. I normally use 128 as the buffer size but I increased it in order to get more frequent xruns. An other observation is the schedutil is closer to the performance governor in terms of xruns at 1000Hz but there is a bigger gap between both at 250Hz.

I'm still wondering if it wouldn't make sense to keep 250hz as the default as my usage is quite an edge case I would say.