support user-defined processor restriction

[ompiteam]

Use sched_getaffinity etc. to restrict discovery to the current cpumask.

1. Add a configuration flag to limit the discovery to the current binding of the process. Could let the user choose between using the CPU or using the memory binding, and between using the current process or the current thread binding. But those variants are not very important and they can be implemented with (2) anyway. So just keep the important variant(s?). I'd say the current thread CPU binding (HWLOC_TOPOLOGY_FLAG_RESTRICT_TO_BINDING)

(2) Add a configuration function to limit the discovery to a given cpuset. To get the current binding of the process, one has to run a first discovery, then use get_cpubind, then run a second one with the configuration. This is tedious, the API works this way.

hwloc_topology_restrict_to_cpuset(topology, cpuset);

(no need for a nodeset flavor, it won't be used often, and we have conversion functions anyway)

(3) Add a function to restrict a discovered topology to a given cpuset. This looks like within the scope of the functions we are thinking about for network use (extract part of a topology, merge topologies).

[ompiteam]

Imported from trac issue 12. Created by sthibaul on 2009-09-27T09:38:52, last modified: 2012-12-22T03:25:14

[ompiteam]

Trac comment by bgoglin on 2009-11-05 01:42:39:

We'll probably want hwloc_get_cpubind() in 1.0 for other reason (PLPA, ...) so I think we can move this ticket to the 1.0 milestone as well.

[ompiteam]

Trac comment by sthibaul on 2010-02-14 15:47:12:

The get_cpubind function is already in.
There are several ways I can see

• Add a configuration flag to limit the discovery to the current binding of the process
• Add a configuration function to limit the discovery to a given cpuset. To get the current binding of the process, one has to run a first discovery, then use get_cpubind, then run a second one with the configuration. This is tedious, the API works this way.
• Add a function to restrict a discovered topology to a given cpuset. This looks like within the scope of the functions we are thinking about for network use (extract part of a topology, merge topologies).

Do we still want this for 1.0?

[ompiteam]

Trac comment by bgoglin on 2010-02-28 07:52:19:

Move this to 1.1 since Ashley doesn't seem to need it.

[ompiteam]

Trac comment by bgoglin on 2010-10-24 14:11:53:

move this to 1.2, too late to discuss for 1.1

[ompiteam]

Trac comment by bgoglin on 2011-02-02 11:49:16:

Copy Samuel's ideas from above into the core of the ticket, and add comments.

I don't understand the third point. Does it refer to when we thought we would have cpusets covering multiple machines at the same time ? It looks like we switched to single-machine cpusets and NULL cpusets for multiple-machine objects now.

[ompiteam]

Trac comment by sthibaul on 2011-02-03 10:00:56:

Does it refer to when we thought we would have cpusets covering multiple machines at the same time ?

No, I never thought that, actually :)

I just meant it's the same kind of operation which should probably go to the same documentation part: you have an existing topology object, and you build another one from that. Restricting to a cpuset is just a kind of operation, just like you could want to restrict to a subtree (when you don't have a cpuset to designate the part you want to keep, e.g. network topologies), merge some parts of a machine, or different machines, etc.

[ompiteam]

Trac comment by bgoglin on 2011-02-04 05:24:34:

(In [3153]) Branch to work on topology restriction

Refs #12

[ompiteam]

Trac comment by bgoglin on 2011-03-16 11:28:21:

(In [3268]) Merge the restrict branch intro trunk

This introduces:
hwloc_topology_restrict(topology, cpuset, flags)
and
lstopo --restrict

This commit fixes #12

[ompiteam]

Trac comment by bgoglin on 2011-08-20 03:08:32:

Milestone v1.2 deleted