Antoine Pitrou added the comment:
Here is a patch removing cpu_set and using sets of integers instead.
--
Added file: http://bugs.python.org/file26682/cpuset.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12655
Changes by Antoine Pitrou pit...@free.fr:
Removed file: http://bugs.python.org/file26682/cpuset.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12655
___
Changes by Antoine Pitrou pit...@free.fr:
Added file: http://bugs.python.org/file26683/cpuset.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12655
___
STINNER Victor added the comment:
sched_getaffinity() does not fail if the set is smaller than the
number of CPU. Try with an initial value of ncpus=1. So we cannot
start the heuristic with ncpus=16, because it would only return 16
even if the computer has more cpus.
Instead of this heuristic,
Antoine Pitrou added the comment:
Try with an initial value of ncpus=1.
Well, I've tried and it works:
os.sched_getaffinity(0)
{0, 1, 2, 3}
I don't know if CPU_SETSIZE is part of the standard (POSIX?).
These are Linux-specific functions.
--
STINNER Victor added the comment:
Try with an initial value of ncpus=1.
Well, I've tried and it works:
Oh, you're right :-) I only checked ncpus (1), not the final result.
It works because CPU_ALLOC_SIZE() rounds the size using
sizeof(unsigned long) (64 bits on my CPU). So CPU_ALLOC_SIZE(1)
Giampaolo Rodola' added the comment:
+1 for Antoine's patch/approach: it's more usable and pythonic.
I think documentation should mention and link the existence of:
http://docs.python.org/library/multiprocessing.html#multiprocessing.cpu_count
--
___
Serhiy Storchaka added the comment:
You may also use a constant size (CPU_SETSIZE) of the set used by
sched_setaffinity() to simplify the code.
As Antoine pointed out to me (and I was convinced itself, experimented with an
example from man:CPU_SET(3)) the cpu_set functions work with a sets of
Roundup Robot added the comment:
New changeset d6745ddbccbd by Antoine Pitrou in branch 'default':
Issue #12655: Instead of requiring a custom type, os.sched_getaffinity and
http://hg.python.org/cpython/rev/d6745ddbccbd
--
___
Python tracker
Antoine Pitrou added the comment:
Ok, I've improved the default ncpus value and committed.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12655
Roundup Robot added the comment:
New changeset fb975cb8fb45 by Victor Stinner in branch 'default':
Issue #12655: Mention multiprocessing.cpu_count() in os.sched_getaffinity() doc
http://hg.python.org/cpython/rev/fb975cb8fb45
--
___
Python tracker
STINNER Victor added the comment:
I'm sorry, I missed this issue. I just saw its API and I have remarks on the
cpu_set type:
* Why not reusing the set type for input parameters and the result of
sched_getaffinity?
* Method names of cpu_set are very different than names of the set type
* Why
Antoine Pitrou added the comment:
Is it possible to get the number of CPU to be able to convert a Python
set to a cpu_set?
sched_getaffinity returns EINVAL if the cpu_set is too small, so it should be
easy enough to iterate.
I agree the API should be changed for something saner, and before
Benjamin Peterson added the comment:
Using a Python set is fine.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12655
___
___
Python-bugs-list
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
nosy: +giampaolo.rodola
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12655
___
___
Matt Joiner anacro...@gmail.com added the comment:
Please also expose sched_getcpu().
--
nosy: +anacrolix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12655
___
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset 89e92e684b37 by Benjamin Peterson in branch 'default':
expose sched.h functions (closes #12655)
http://hg.python.org/cpython/rev/89e92e684b37
--
nosy: +python-dev
resolution: - fixed
stage: patch review -
Charles-François Natali neolo...@free.fr added the comment:
I actually implemented this because I wanted to confine a Python process to a
cpu to prevent keep it from being tossed from core to core. It made sense to
bring the other scheduling functions along for the ride.
Why didn't you use
Benjamin Peterson benja...@python.org added the comment:
2011/7/30 Charles-François Natali rep...@bugs.python.org:
Charles-François Natali neolo...@free.fr added the comment:
I actually implemented this because I wanted to confine a Python process to
a cpu to prevent keep it from being
Changes by Benjamin Peterson benja...@python.org:
Added file: http://bugs.python.org/file22805/sched_stuff.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12655
___
New submission from Benjamin Peterson benja...@python.org:
For fun and profit. :)
--
components: Extension Modules
files: sched_stuff.patch
keywords: patch
messages: 141401
nosy: benjamin.peterson, pitrou
priority: normal
severity: normal
status: open
title: Expose sched.h functions
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
@@ -10330,26 +10899,34 @@ INITFUNC(void)
I know that it's only an increase of 5%, but I feel that posixmodule.c is
already large enough.
Does this feature belongs to the os module?
Or is it time to split posixmodule.c in several
Benjamin Peterson benja...@python.org added the comment:
2011/7/29 Amaury Forgeot d'Arc rep...@bugs.python.org:
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
@@ -10330,26 +10899,34 @@ INITFUNC(void)
I know that it's only an increase of 5%, but I feel that posixmodule.c is
Antoine Pitrou pit...@free.fr added the comment:
Haven't reviewed the implementation, but +1 for adding this functionality.
As for splitting apart posixmodule.c, I agree that's a separate concern.
Something like the _io module splitup (several C files compiled in a single
extension module)
Charles-François Natali neolo...@free.fr added the comment:
I'm +0.
It would certainly be fun, but I'm not so sure about the profit part.
The main usage of the scheduler API is for real-time policies, and I
somehow doubt Python is commonly used in this area (but I could be
wrong).
Furthermore,
Benjamin Peterson benja...@python.org added the comment:
I actually implemented this because I wanted to confine a Python process to a
cpu to prevent keep it from being tossed from core to core. It made sense to
bring the other scheduling functions along for the ride.
--
Changes by Benjamin Peterson benja...@python.org:
Added file: http://bugs.python.org/file22797/sched_stuff.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12655
___
27 matches
Mail list logo
