The dirty ratio for laptop mode tools is set incorrectly, and even worse for users on battery. Use the following configuration to retain defaults set in Liquorix.

/etc/laptop-mode/laptop-mode.conf


The settings for LM_DIRTY_(BACKGROUND_)RATIO are unimportant when laptop_mode is enabled. The laptop_mode boolean setting in the kernel makes sure that when the disk spins up, all dirty pages are written to the disk to prevent future spin ups from occurring too frequently. In effect, the dirty_background_ratio sysctl is useless when you're in laptop_mode.

< Edited by damentz :: Oct 31, 21, 17:00 >
Back to top

Nice info damentz...why not look for other good tweaks for laptop owners to tweak to make the machine responsive and yet not slow apps or anything else down.

My IBM Thinkpad T42 has just a 1.8 GHz Pentium M but 2GB RAM and a 2MB L2 cache helps it along.
Back to top

Damentz, looks like laptop-mode-tools has been pretty much deprecated as pm-utils implements many of the functions of laptop-mode-tools. Have you got to check into how to use such tweaks in pm-utils?
Back to top

laptop-mode-tools is a service that runs and configures your system whenever you switch from a plug to battery. From what I'm reading, pm-utils is a collection of scripts used to suspend or hibernate your system.

If pm-utils is deprecating laptop-mode-tools, then I'm really scared.
Back to top

Does this fix still need to be applied with the newest kernel? I just started using liquorix kernel recently and found this topic.

Thanks
joshritger


PS, what does this do, I am not familiar with it.
Back to top

Yes, laptop-mode-tools overrides the writeback settings in /proc/kernel/vm whenever the daemon initializes to whatever you put into /etc/laptop-mode/laptop-mode.conf

You can add these settings at your discretion, it's just a personal preference of mine that these ratios be set. Otherwise, you could lose a lot of throughput without these changes.
Back to top

I just want to provide an up-to-date information on how to restore the tweaked writeback ratios from the liquorix kernel.

Package pm-utils in recent distros has an integrated laptop-mode ruleset for power management. This means that even without having the laptop-mode-tools package installed, the tweaked writeback ratios are overriden each time by a ruleset from this package.

To recover the tweaked ratios, one must edit and change the following to These variables are used when the machine is running on battery. When running on AC, one must also change the following to One could also tweak vm.writeback_centisecs sysctl via the LAPTOP_DIRTY_WRITEBACK=${LAPTOP_DIRTY_WRITEBACK:-60000} line while on battery, and from the fourth param of the write_values call inside the laptop_mode_ac function while on AC.
Back to top

Is there no way to configure pm-utils from /etc? If the package maintainer releases a new version of this package, your changes will be overwritten.
Back to top

I understand that the above workaround is less than optimal, given the chance of an overwrite in case the package gets updated.

But for the moment, I have not yet found any other way to revert the changes, other than
or remove the package entirely if not needed (but one loses other power management functions) if so desired.

Making relevant changes inside /etc/sysctl.conf doesn't help as long as pm-utils is installed, or the script is executable. There doesn't seem to be any tweakable options inside /etc relevant to pm-utils.
Back to top

If tampering with files in /usr is indeed the only way to achieve this, and the underlying filesystem is ext[234] or some other that supports file attributes, one of the possible options of preventing future upgrades from overwriting your changes could be this:

See man chattr for more info. This basically makes the file immutable.
From the man page:

You can later view file attributes using lsattr, or remove the "immutable" attribute with chattr -i.

This is however just an untested suggestion/idea at the time, and is actually a very ugly workaround/kludge for the problem, and you have to be aware of what exactly using it means for you. Basically, it is entirely possible that some future upgrade of the pm-utils package might fail because the upgrade script will be denied write access to the file, or the upgrade might go fine but the newer version might contain some (possibly important) patch/fix that won't end up on your system (again, because the file cannot be written to). And it's also very easy to forget you ever set that attribute, so you might end up spending hours or even days trying to figure it out... So yeah, beware.
Back to top