Friends, I have noticed a huge difference in performance between the 6.0.0-4mx-amd64 kernel and the 6.0.0-11.2-liquorix-amd64 kernel, with the latter being the winner.

With the version of licorix that I mentioned before I can work well with the problem that when passing the data from the fixed memory to the swap the equipment slows down but after 10 to 15 seconds it recovers its normal speed and I can work fine. On the other hand, with the latest kernel packaged by mx, the computer feels very fast until it starts using the swap and as the seconds go by the slowness does not disappear; Same for Debian kernel 5.10.0.19.

I think licorix has worked some magic to improve swap usage, although it still needs to be improved so that it doesn't slow down when transferring data from memory to swap.

Is there a way to improve this?
Back to top

Zen-Kernel / Liquorix contains an optimization we borrowed from ChromeOS to improve performance of swap: github.com/zen-kernel/zen-kernel/commit/5cd904f6d3a9b52b216d6d875e62c457b0d6a7c6

If you have a quick way to reproduce the scenario you're running into, try running sudo sysctl vm.page-cluster=3 to restore the default Linux swap readahead and compare.
Back to top

I did what you told me, but nothing did not improve.

I have also added these values ​​in /etc/sysctl.conf , with no success yet:

vm.swappiness = 15
vm.vfs_cache_pressure = 50
vm.dirty_ratio = 3
vm.page-cluster=3

I also find other errors for example:

1) when it consumes more than 3gb of exchange it gets very slow

2) On the internet they say that the maximum swap is 2gb for equipment with more than 4gb of ram. Therefore, I put 2gb of swap.

It happens that when it reaches the top of the 2gb swap, at times it slows down, opening a little more than 1.5gb in available ram. That is to say, it seems that the kernel does not realize that the swap has run out, but it has space available in the ram. After several seconds the slowness is removed.

If you can help me I am open to do the necessary tests.
Back to top

Something weird is going on here: reading I found that I could use swap in ram with a kernel module called zram.

Well, that's how I did it, but the strange thing is that when the paging starts, it slows down for a few seconds in my applications: chrome, vscode and evernote. By slow I mean that a small freeze happens and after a few seconds, everything returns to its normal state.

I was afraid that the error was due to the speed of my HDD, but now I'm coming to think that the problem is mostly logical (software) instead of physical.

I am using this version of the kernel, which in my opinion is the fastest:
Linux JuanDavid 6.0.0-11.2-liquorix-amd64 #1 ZEN SMP PREEMPT_DYNAMIC liquorix 6.0-8.1~bullseye (2022-12-02 x86_64 GNU/Linux
Back to top

Overall what you're describing is the default behavior of Linux and is not unique to Liquorix. Swap has never been fast and always causes problems to running applications. It causes a type of "stop the world" type impact similar to what you'd see on a JVM doing full garbage collection.

If your desire is to get rid of that behavior, your only real option is to disable swap entirely and install more RAM on your device. Of course, a newer kernel might help as code is optimized over time for any reason.
Back to top

@damentz thanks for keeping an eye on this post.

Look, I checked zram on the debian 5.10 kernel and the latest kernel packaged by mxlinux 6.0, and as you said they suffer from that "stop the world" type impact, but doing tests I set the aggressiveness of kswapd, which I understand is the service or daemon that manages sharing with this property in /etc/sysctl.conf:

vm.watermark_scale_factor = 200.

and this did the magic. When paging is done the system no longer suffers from that "stop the world" type shock. Just a little slow but for example chrome no longer gets stuck when I go to open a new tab or evernote doesn't freeze.

I have to say that this only works with the liquorix kernel; so thank you guys for the excellent job you have done. Without a doubt, liquorix is ​​the one that best manages swap memory.

as against this solution is that the system consumes 200 to 300 mb more than when it is disabled; but what is that with the benefit of a system that does not freeze.

Well, nothing, happy to see this problem solved and well, keep improving this kernel that shows that they care about the well-being of the users.

edited: with vm.watermark_scale_factor = 250 there is no slowness when using swap.

It remains to be improved that the system slows down when it reaches the top of the swap even with available ram space.

Thanks a lot!!!
Back to top