This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
On Thu, 2009-10-22 at 11:05 +0200, Brice Goglin wrote:
> Ashley Pittman wrote:
> > Does this imply the default is to report on processes in the current
> > cpuset rather than the entire system? Does anyone else feel that
> > violates the principal of least surprise?
> Yes, by default, it's the current cpuset. Maybe lstopo should report the
> whole system (it does if you pass --whole-system), or display a clear
> message saying that's it's only showing the current cpuset. Apart from
> lstopo, for real applications, I feel like using the current cpuset only
> is better.
I guess 95% of the time you run it by hand you won't have a cpuset so
it'll be the same anyway and when you do have a cpuset then it's
probably what you are interested in.
Could I add a feature request that you can query the topology for other
arbitrary processes in the system? I've taken a look at the source and
it appears I could add this for Linux easily enough (I assume I could
just change /proc/self/ in src/topology-linux.c:1005?) but doing the
same for other operating systems isn't something I could do.
It would be a two minute job to add this to padb which would allow you
to see the topology of all processes within a parallel job at run-time
without needing to interrupt the job.
Ashley Pittman, Bath, UK.
Padb - A parallel job inspection tool for cluster computing