-
Notifications
You must be signed in to change notification settings - Fork 190
hwloc-affinity #359
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
hwloc-affinity #359
Conversation
Interesting :) In cpuaffinity_exec, I believe you need to add a synchronization between the child and the parent. Otherwise the child might have the time to clone() before the parent manages to call ptrace(). |
Options -i and --input should use the existing helpers in utils.h so that they handle XML/CPUID/Synthetic etc. There's also some duplication in hwloc_obj_from_string() which already exists as generic helpers in hwloc-calc.h with support for ranges etc. If it's only needed for --restrict obj:X, we should extend --restrict in other tools to also support object specifications. Things should be uniform there. Unfortunately, once you start doing that, it means you need to support both physical and logical specification with command-line options. I wonder if we should just use --restrict cpuset and keep telling people to use hwloc-calc for generating the cpuset. Or we should support foo:Px and foo:Lx for logical and physical indexes. The scatter policy already exists in hwloc-distrib, which could also be extended to export objects and/or indexes. I think this should be split into two parts:
|
Signed-off-by: Nicolas Denoyelle <[email protected]>
…lstopo into hwloc-affinity Signed-off-by: Nicolas Denoyelle <[email protected]>
…lstopo into hwloc-affinity Signed-off-by: Nicolas Denoyelle <[email protected]>
Signed-off-by: Nicolas Denoyelle <[email protected]>
Signed-off-by: Nicolas Denoyelle <[email protected]>
Signed-off-by: Nicolas Denoyelle <[email protected]>
Signed-off-by: Nicolas Denoyelle <[email protected]>
Signed-off-by: Nicolas Denoyelle <[email protected]>
Signed-off-by: Nicolas Denoyelle <[email protected]>
Signed-off-by: Nicolas Denoyelle <[email protected]>
Signed-off-by: Nicolas Denoyelle <[email protected]>
Signed-off-by: Nicolas Denoyelle <[email protected]>
You should likely split this PR in small and easier-to-review pieces to ease its converging/merging. One first good step would be to just add hwloc-bind-threads, with this as a possible usage:
Where -t core means we're binding the first thread to first core, second thread to second core, etc. And last threads are not bound if there aren't enough cores. Or option to wrap-around.
This would bind each thread to its respective location if any, where location is implemented exactly as in hwloc-calc/bind/... Add --single and --strict just like in hwloc-bind. Unless I am mistaken, Linux is the only OS where a process can bind a thread of another process, hence all this can be made Linux-specific. And add a basic test that counts the number of cores, spawns N+1 threads with pthread_create and they check their own binding once ptrace had time to bind them. Not sure testing with OpenMP is a good idea because the way OS threads are created and given to user OpenMP tasks can vary from one implementation to another. |
Actually I believe windows can as well, by using OpenThread to get a handle on the thread to be bound |
In order to call OpenThread, you have to know which thread to open. ptrace allow to hook on threads |
Forget about Windows for now, there are too many missing pieces there. Make all your thread-binding stuff Linux-specific as I said 17 days ago. |
Thanks for all the updates. Taking a step back, though, I see a lot of other pthread tests in configure already, and I see pthread code used throughout the rest of hwloc. Is there really a need for your new configure test? Or does your new pthread-using C code just need to be protected by existing macros? |
ptrace configure tests are running in the scope of macros used for hwloc utilities.
hwloc does not define macro HAVE_PTHREAD. pthread is required to enable some tests at make check. If it is not defined then tests do not run. I think there is a need for this test in order to
I am working on it. I'll do one branche and one PR per feature as you proposed. |
@NicolasDenoyelle Thanks for investigating the configury stuff (embedded, etc.). |
Note to open pull requests: some things changed in the CI yesterday, you'll need to rebase on top of master to avoid total CI failure. |
Extend hwloc utilities with a tool to bind threads to single processing units with a policy.