[SOLVED] Init scripts and changing cpu affinity with taskset

[zirtik]

Hi,

I have a 6-core system and I would like to change the affinity of all processes to restrict them to use only the first four cores. I know what I'm doing, and I'll use the last two cores for a special purpose. I created a new init script under /etc/init.d/affty and here is its contents:

Code: Select all

#!/sbin/runscript

description="Set processor affinity"

depend() {
        before *
}

start() {
        /usr/bin/taskset -cp 0,1,2,3 1
        /usr/bin/taskset -cp 0,1,2,3 $$
}

I added the script to sysinit runlevel by issuing:

Code: Select all

rc-update add /etc/init.d/affty sysinit 

and restarted my computer. However, when I run:

Code: Select all

taskset -p 1

I see that it can still use all cores available in the system. Also, if I run:

Code: Select all

rc-status sysinit

I see that affty is not started. The weirdest thing is that this only happens in one computer. I have the same exact hardware with the same configuration and that one seems to work just fine.

Any ideas? I've been stuck with this for over two days already.

[SlashBeast]

You better use cgroups's cpuset to do it. Or hack runscript.sh to exec your fancy app always, whenever runscript is done.

[zirtik]

Thank you. But I have a pretty good feeling that it has something to do with the launching of the init script. The same configuration works in my other machine. When I type

Code: Select all

/etc/init.d/affty status

I can see that the service has been stopped. What would cause this?

[zirtik]

I just did an

Code: Select all

rc-update -u

and rebuilt the dependency tree. It solved the problem.

[steveL]

Only thing that stuck out was:

Code: Select all

rc-update add /etc/init.d/affty sysinit

which is more usually done as:

Code: Select all

rc-update add affty sysinit

(just for future ref, in case it makes a difference; the dependency calculation is normally done at reboot, so if you weren't rebooting that might explain it.)

[zirtik]

I was actually rebooting it but for some reason it didn't work. Do you think specifying the full path as

Code: Select all

/etc/init.d/affty

was the problem that messed up the dependency calculation?

[steveL]

I'm not sure, but it could be; someone else was trying to get a script in /opt to run and, while rc-update seemed to accept the path, it didn't actually boot.

[zirtik]

Alright, thank you steveL. I'll keep that in mind.

[steveL]

You're welcome zirtik :)

FWIW I found a relevant bug when I looked to report the issue of rc-update accepting paths which it then didn't boot. This is the other topic where it happened (with a path in /opt.)

The linked one shows there was a problem, but I think that could be fixed with applet = basename_c(argv[1]); instead of applet = basename_c(service); which would allow the use of service = realpath(argv[1], NULL);.

Hopefully it'll get fixed soon.