Process CPU affinity

[GoogleCodeExporter]

Proposal
This follows ml proposal:
https://groups.google.com/forum/#!topic/psutil/q9nJ1SZdqe0
...and it is well explained here:
http://www.linuxjournal.com/article/6799?page=0,0

CPU affinity consists in telling the OS to run a certain process on a limited 
set of CPUs only.
On Linux, this can be done via taskset command.
For example, to run process with PID 7824 on CPUs 0 and 1 only:

giampaolo@ubuntu:~$ taskset -c -p 0,1 7824
pid 7824's current affinity list: 0
pid 7824's new affinity list: 0,1

On what platforms would this be available?
Linux and Windows.

Proposed API
The API I have in mind follows the same we used for psutil.Process.nice: a r/w 
property which can be used for both getting and setting the new value.
More or less:

>>> p = psutil.Process(os.getpid())
>>> p.cpu_affinity
[0]
>>> p.cpu_affinity = [0, 1]
>>> p.cpu_affinity
[0, 1]
>>> p.cpu_affinity = [0, 1, 2, 30]
Traceback:
...
ValueError: invalid cpu 30 
>>>

Are there existent implementations we can use as an example?
http://pypi.python.org/pypi/affinity/0.1.0

Original issue reported on code.google.com by g.rodola on 20 Dec 2011 at 7:08

[GoogleCodeExporter]

Preliminary Linux patch in attachment.
I'm still not sure whether I like the property-based API though.
Alternatives:

>>> p.cpu_affinity()  # get
[0]
>>> p.cpu_affinity([0])  # set
>>>

...or:

>>> p.get_cpu_affinity()  # get
[0]
>>> p.set_cpu_affinity([0])  # set
>>>

Original comment by g.rodola on 21 Dec 2011 at 12:05

Attachments:

• cpu-affinity-linux.patch

[GoogleCodeExporter]

One tip regarding implementation - original affinity implementation has a bug, 
which makes it unusable in some Linux environments (for example CentOS 5.5). I 
am using a alternative implementation from: 
http://alioth.debian.org/tracker/index.php?func=detail&aid=311537&group_id=30402
&atid=411002 which seems to work for my cases.

Would it be possible to call it in following manner: 
p = psutil.Process(0)
p.cpu_affinity = [0, 1]
sp = subprocess.Popen(...)

With current affinity implementation it allows to set an affinity for spawned 
process in advance.

Original comment by maciej.l...@gmail.com on 21 Dec 2011 at 7:52

[GoogleCodeExporter]

What's the problem? PID 0?
This works for me:

>>> import psutil
>>> p = psutil.Process(0)
>>> p.cpu_affinity
[0, 1]
>>> p.cpu_affinity = [0]
>>> p.cpu_affinity
[0]
>>> 

Original comment by g.rodola on 21 Dec 2011 at 11:25

[GoogleCodeExporter]

Linux implementation committed in r1246.
As for now I choose the following API but I know myself, and I might change my 
mind later =):

>>> get_cpu_affinity()
[0,1]
>>> set_cpu_affinity([0,1])
>>>

Original comment by g.rodola on 23 Dec 2011 at 9:03

• Changed state: Started

[GoogleCodeExporter]

Windows implementation committed in r1249.

Original comment by g.rodola on 25 Dec 2011 at 2:56

• Changed state: FixedInSVN

[GoogleCodeExporter]

Note to self - python 3.3. exposed different sched.h functions:
http://docs.python.org/dev/whatsnew/3.3.html#os
http://bugs.python.org/issue12655
http://docs.python.org/dev/library/os.html#interface-to-the-scheduler
It might be worth to take a look and figure out whether we can include some of 
those in psutil.

Original comment by g.rodola on 17 Feb 2012 at 11:54

[GoogleCodeExporter]

0.5.0 is finally out. Closing out as fixed.

Original comment by g.rodola on 27 Jun 2012 at 6:54

• Changed state: Fixed

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Updated csets after the SVN -> Mercurial migration:
r1246 == revision 9235dc5f5a15
r1249 == revision 566889617340

Original comment by g.rodola on 2 Mar 2013 at 12:06

[GoogleCodeExporter]

Hi, is there a plan to pursue the implementation of cpu_affinity on OS X in the 
future?  I know Apple has made it difficult by "not exporting interfaces to 
processor control"... Thanks.

Original comment by paul.qu...@gmail.com on 9 May 2013 at 7:16

[GoogleCodeExporter]

When I looked into OSX implementation it seemed this wasn't possible.
If you have any reference / pointers please share.

Original comment by g.rodola on 9 May 2013 at 11:05