nefelim4ag
commented
6 years ago Sorry for long answer, just no spare time.
I understood what you want and also think about that, but it's create to many problems for just set appropriate priority to processes.
In kernel fix, just a bad idea, thats are user space problem.
PATH magic will create too many overhead for process starting and will not work always, as example for steam that will not work. For gcc that will create noticeable overhead.
That can work and may be useful for some thing, but for that we need much more smart method to gen overwrites in /usr/local/bin. For make and other rare called stuff that can work.
If you wish, you can play with that, i'm not refuse, i'm just think that not worth of work.
May be at first ananicy must be rewritten by some more efficient lang (CPU/Memory) then bash. (I'm also not sure if that worth of resources). Because wrap processes with bash script which fork() & execv() several other tools, looks too costly.
Thanks.
I think we can all agree that it's a problem that ananicy doesn't apply the settings right away when a process is created. That is because it runs each rule with pgrep and other applications at a time with a sleep time in between the calls. That is to ensure that ananicy does not take up too much CPU time. A better solution would be to either have the settings be applied at process creation or shortly after.
There are two possible solutions to do this:
Dynamically create wrapper scripts in /usr/local/bin that call the process with the arguments, but with
niceand other applications prior to apply the settings. That should work fine for interpreted languages, too, because the called script is visible in the passed arguments. E.g.python foo.pyormono --debug /usr/lib/smuxi/smuxi-frontend-gnome.exe, in the case of the Smuxi IRC/Chat client. That would necessitate the creation of those files, obviously, which is disk IO. It is possible to fix this possible issue by using overlayfs to create the wrapper scripts in a virtual (memory only) file system, so no disk IO is performed when the rules are loaded. That would entail mounting said overlayfs over /usr/local/bin. This solution could be worked around by calling the applications by their name (/bin/gcc). If that is no problem, this solution seems to be good.Set the values at process creation in kernel space. The idea is to cache the rule set in kernel space and apply the rules when the process is created. It is necessary to hook that event, which I don't know how.