Performance parameter tuning problem

Had to ask.

Sorry, I don’t get it either.

Is there something or app may override system parameter?

Maybe another udev rule.

Does it work if you tell it to manually?

sysctl vm.dirty_expire_centisecs=300

(then check again sysctl -a | grep dirty)

it works.

~/.config/awesome >>> sudo sysctl vm.dirty_expire_centisecs=300                                            ±[●●][master]
vm.dirty_expire_centisecs = 300

That won’t stick.

I know, but it at least tells us it ‘works’.
Now, what could be overriding 99-sysctl.conf … and/or Why arent options there doing anything?
Thats still a mystery.
At the very least, as shown, it can be added to startup until the culprit is discovered.
It seems like it should be a typo/pebcak/something problem … but if the outputs are right it isnt.

It’s beyond me, a kernel param?

He could hack a fix by writing a start up service.

Oh yeah OT -
That reminds me I need to update that other thread … apparently the trick was a domino of services (first nmcli off, then unload module before suspend … after suspend reload module then nmcli on [4 services])

WTF, why would it take 4 services.

I’ve gotten in the habit of doing a nmcl network on/off pre/post as well. Only it usually works all in 2 scripts/services.

1 Like

More OT
But because
-Each service need a twin (one for off/before and one for on/after)
-The nmcli command runs in userspace, whereas the module loading/unloading is done by root
[thats your 2x2=4]
-Then of course is the cascade effect that each relies on the other and suspend upon them.

It shouldnt have been that hard, but I found that unloading/reloading the module was required for the workaround to be always effective.

1 Like

Well there you go. Curiouser, and curiouser.

Try this.

login as root:

su

Enter your root pasword, then:

echo "300" > /proc/sys/vm/dirty_expire_centisecs

Then just to be sure:

cat /proc/sys/vm/dirty_expire_centisecs

Reboot, and confirm.

Finally I tested and found what overrides this, it’s tlp.service. when I disabled tlp, it works OK and setting is sticky, if enable tlp service, value will be reset to 1500.
I haven’t figure out why tlp will do this and which tlp config include these settings.
However, maybe we can tune the sequence of startup of tlp service and others like rc.local service, then tlp will have no chance to reset this value.

1 Like

Good work on tracking that down. How did you figure out what was causing it.

en…I have searched out this post: https://bbs.archlinux.org/viewtopic.php?id=167678, it said pm-utils will override /etc/sysctl.conf, but I don’t install this package, so I guess it may be something like power management, xfce4-power-manager or tlp etc.
When disabled xfce4-power-manager, not working, until disabled tlp, it’s working. that’s all.:sweat_smile:

1 Like

If you have similar issue, two solutions(tested myself) may work for you:

  1. If you do not want power saver and installed tlp, you can disable tlp.service.
  2. Tuning the order of service or script setting this parameter after startup of tlp.service.
    my rc-local.service works for me:blush:
[Unit]
Description=/etc/rc.local Compatibility
ConditionPathExists=/etc/rc.local
After=multi-user.target tlp.service

[Service]
Type=forking
ExecStart=/etc/rc.local &
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=no
SysVStartPriority=99

[Install]
WantedBy=multi-user.target
2 Likes

:thinking: But you know that you shouldnt use the rc.local anymore? It was an ugly hack in the days we didnt have anything better.

Well, I know rc.local is not recommended now. I just couldn’t find a better way and I want to say “Every man has his hobbyhorse”. :smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by Bytemark