maxperfwiz script

My 0.02€:

  1. Wherever the parameter explanation starts with Contains, add the parameter name to the description:

    E.G. make this:

      # vm.dirty_ratio
      fold -s <<< "Contains, as a percentage of total available memory...

    into this:

      # vm.dirty_ratio
      fold -s <<< "The vm.dirty_ration contains a percentage of total available memory...
  2. Remove strike-through here:

    Dirty expire centisecs tunable is used

  3. shcedulerscheduler

  4. Check whether you're running as root? Answered below.

  5. I've already given feed-back on the values of the parameters above so nothing to contribute there any more... :innocent:

1 Like

No need for it. The only command that requires sudo is copying the temporary files to their appropriate config directory. When all of the tweaks have been selected and written to a temporary file, the file is displayed to the user and upon confirmation, the script runs sudo cp ...and the user is prompted to enter the password. Much better than running the entire script with sudo.


I think I have addressed all of those concerns besides the centisecs one.
(see gitlab)
I tried to look it up .. but maybe all my sources were speaking to rotational disks.
Do you care to explain ?

Absolutely true: most literature still refers to rotational disks. The only one that I could find that takes into account SSDs and NVMes in 15 min of Google-fu is this one.

Having said that, the numbers I gave were based on the following Solid State characteristics:

  • Seek time is near 0
  • Write time is 5x at a minimum = QSLC compared to HDD
  • Read time is 10x compared to HDD.
  • Extensive testing.

If you don't like my numbers and want to be conservative take SSD = HDD/2
My numbers are HDD/6 which might be a bit sharp for most people out there so in maxperf HDD/5 should be safe for 95% of users out there.

I'll PM you where these numbers come from...


2 things:

In line 198 you are missing a "

Can somebody test is in Pinebook Pro and see if there is any diference? I have been testing it on a VM and there is a differnce.

oops. thanks, I fixed that.
..and sorry no access to the PBP :woman_shrugging:

A question - Does it require to disable TLP to avoid problems, and if yes, what should be the best way to disable tlp that it does not causes problems.

Harmless and doesnt require disable of TLP .. there are just 2 tweaks that are probably usurped by TLP
(if TLP is running and those options are set by TLP, the option created by the script will do nothing)

1 Like

thanks for the quick reply. :+1:

Doing some tests on a vm (Virtualbox)

When setting kernel.nmi_watchdog to 0, during the boot process I get in journalctl:

systemd[1]: Failed to start Apply Kernel Variables.
systemd[1]: systemd-sysctl.service: Failed with result 'exit-code'.
systemd[1]: systemd-sysctl.service: Main process exited, code=exited, status=1/FAILURE
systemd-sysctl[1591]: Couldn't write '0' to 'kernel/nmi_watchdog': Cannot allocate memory

I added a kernel parameter:


Same thing.

I blacklisted in /ect/modprobe.d/modprobe.conf as follows:

blacklist iTCO_wdt
blacklist iTCO_vendor_support

The same error keeps popping up.

1 Like

The script does not, and probably wont, blacklist modules.

Do you know what module is is causing watchdog ?
lsmod | grep TC on second thought .. maybe it wouldnt be a terrible idea to try and find say, bluetooth modules and give the option to blacklist them ..

lsmod | grep TC does not return anything. maybe the error has to do that the system is a vm. Just guessing.

Also maybe you could expand the info text for watchdog and say" In some instances this could cause..... so please check ..... with this command" or something like it

Do me a favor?
Check these:

lsmod | grep -E 'TC|wdt|dog|sbc|cpwd|riowd|mixcomwd|zwd|ibmasr|i6300esb'

(newer lsmod now should contain most if not all possible watchdog modules)

lsmod again no output

wdctl: No default device is available.: No such file or directory

Also here is the strace

openat(AT_FDCWD, "/proc/sys/kernel/nmi_watchdog", O_WRONLY|O_CLOEXEC) = 3
write(3, "0\n", 2)                      = -1 ENOTSUPP (Unknown error 524)
close(3)                                = 0
writev(2, [{iov_base="Couldn't write '0' to 'kernel/nm"..., iov_len=67}, {iov_base="\n", iov_len=1}], 2Couldn't write '0' to 'kernel/nmi_watchdog': Cannot allocate memory
) = 68

Edit: second lsmod you provided, no output either.

Havent seen that before .. you are probably right it has to do with the VM.
I get the same wdctl output when watchdog is disabled.
Along with cat /proc/sys/kernel/watchdog = 0

I can give it a shot with qemu. What do you think?

Edit: cat /proc/sys/kernel/watchdog for me is 1. What the hell ?

Edit 2: Well...daaaah.. It fails so it's 1 !

As long as you dont do anything dodgy and then blame me :wink:

(and a quick search also seems to indicate that unless you add 'virtual watchdog' to the VM it wont have one ... so you are probably in a scenario where the kernel is built with watchdog support and enabled, yet you dont have a corresponding module or configuration.. but dont quote me .. virtualization is not 'my thing')

1 Like

It's a vm. That's what it's for. I 'll check it.

Ok. Created a Manjaro installation in qemu. Loaded virtio modules. Added watchdog hardware. Installed spice and qemu-guest addons. So....
Before your script:

$ lsmod | grep -E 'TC|wdt|dog|sbc|cpwd|riowd|mixcomwd|zwd|ibmasr|i6300esb'
iTCO_wdt               16384  0
iTCO_vendor_support    16384  1 iTCO_wdt
i6300esb               16384  0
$ wdctl
Device:        /dev/watchdog0
Identity:      i6300ESB timer [version 0]
Timeout:       30 seconds
$ cat /proc/sys/kernel/watchdog 


Strace output

openat(AT_FDCWD, "/proc/sys/kernel/nmi_watchdog", O_WRONLY|O_CLOEXEC) = 3
write(3, "0\n", 2)                      = 2
close(3)                                = 0


$ cat /proc/sys/kernel/watchdog 

Conclusion: Oracle, as always, SUUUUUUUUCKS!!!!

Just add a note about VirtualBox in the script.

1 Like

Hello, and thank you for making a wonderful script like this!

Got a quick bug report for yah - the cat /sys/block/*/queue/rotational checks aren't working as expected, which gave me bad values when running the script. Luckily I read the script before I ran it and spotted the discrepancy.

I think the conditional is wrong:

~ >>> bash
[user@user-manjaro-desktop ~ ]$ [[ $(cat /sys/block/*/queue/rotational) == 0 ]] && echo "true!"
[user@user-manjaro-desktop ~ ]$ cat /sys/block/*/queue/rotational
1 Like

Forum kindly sponsored by