Re: [hwloc-devel] processor restriction + lookup of pid for 1.0
On 30 Jan 2010, at 14:57, Samuel Thibault wrote: > Samuel Thibault, le Sat 30 Jan 2010 15:55:00 +0100, a écrit : >> #21 implicitly does: "what cpuset they're bound to" is just an example. >> A configuration function hwloc_topology_set_pid(topology, pid) would >> mean that the discovery has to be done from the view of the given pid, >> and thus the allowed_cpuset should be according to that view, thus >> administrative restrictions. > > Just to give an example: lstopo --pid 1234 would not only show where the > process is currently bound to, but also its allowed cpuset, which can be > useful when monitoring applications run by a batch scheduler or such. Hi, It was my request that caused Jeff to file that enhancement request. My take on this would be that #21 should be interpreted as 'report system state from the point of view of rather than self'. I.e. I don't care which cpuset is shown, the current or the allowed, all I care about is changing the frame of reference so the view is what you would see if the same code was being called from . The reason for this is it's currently possible to do "mpirun lstopo" to see where processes will be bound but it's not possible using lstopo to see the binding of already running jobs. As some of you will be aware I maintain padb, a 'job inspection' tool and I believe lstopo and padb could work together to present a parallel, job-wide view of process binding across a parallel job. I've already added the code to padb to wrap around lstopo, it's available from SVN and has been for some time, it currently runs lstopo for every process within a job on the correct node with the --whole-system option, this means the output is not particuarly relevant though - hence the change request. If you are experimenting with this then the following padb command will allow you to play with the command line options provided, %p will be expanded to the pid. I'm curious to see how this pans out in actual use but I believe it's got potential to be very useful indeed. $ padb --lstopo -Olstopo-show-warning=no -Olstopo-command="lstopo --pid=%p -" -c [ -a | ] I'm aiming to make a padb release in the next month with a being as RC as soon as two weeks away, if I can change the default "lstopo-command" to one that takes a pid before then that would be great, if not padb is future-proof as users can over-ride the default in a configuration file but this raises the barrier somewhat as people would need to be aware that this was an option. Ashley, -- Ashley Pittman, Bath, UK. Padb - A parallel job inspection tool for cluster computing http://padb.pittman.org.uk
Re: [hwloc-devel] processor restriction + lookup of pid for 1.0
Samuel Thibault, le Sat 30 Jan 2010 15:55:00 +0100, a écrit : > > 1) hwloc_topology_from_cpu/membind(pid) (or cpuset as argument) => > > restrict topology to given cpu/membind > > 2) hwloc_topology_get_from_pid(pid) reads both cpu/membind and > > administrative restrictions from another process instead of current process > > No need for these, they'd be contained in the hwloc_topology_set_pid() > configuration function, which is a more powerful way to do it. (plus an additional HWLOC_TOPOLOGY_FLAG_CURRENT_BINDING in hwloc_topology_flags_e, which is the purpose of #12). Samuel
Re: [hwloc-devel] processor restriction + lookup of pid for 1.0
Samuel Thibault, le Sat 30 Jan 2010 15:55:00 +0100, a écrit : > #21 implicitly does: "what cpuset they're bound to" is just an example. > A configuration function hwloc_topology_set_pid(topology, pid) would > mean that the discovery has to be done from the view of the given pid, > and thus the allowed_cpuset should be according to that view, thus > administrative restrictions. Just to give an example: lstopo --pid 1234 would not only show where the process is currently bound to, but also its allowed cpuset, which can be useful when monitoring applications run by a batch scheduler or such. Samuel
Re: [hwloc-devel] processor restriction + lookup of pid for 1.0
Samuel Thibault wrote: > Brice Goglin, le Sat 30 Jan 2010 15:32:51 +0100, a écrit : > >> I still don't see much difference. In #12, you get_cpubind(pid=0) and >> use the resulting cpuset to restrict our topology. In #21, you >> get_cpubind(another pid) and apply the cpuset to restrict our topology >> as well. >> > > No: the administrative restriction cpuset is not the same as the current > cpuset binding of the target process. > Neither #12 nor #21 talks about adminstrative restriction... So we'd need this ? 1) hwloc_topology_from_cpu/membind(pid) (or cpuset as argument) => restrict topology to given cpu/membind 2) hwloc_topology_get_from_pid(pid) reads both cpu/membind and administrative restrictions from another process instead of current process Brice
Re: [hwloc-devel] processor restriction + lookup of pid for 1.0
Brice Goglin, le Sat 30 Jan 2010 15:32:51 +0100, a écrit : > I still don't see much difference. In #12, you get_cpubind(pid=0) and > use the resulting cpuset to restrict our topology. In #21, you > get_cpubind(another pid) and apply the cpuset to restrict our topology > as well. No: the administrative restriction cpuset is not the same as the current cpuset binding of the target process. Samuel
