Re: [hwloc-devel] random api questions
Brice Goglin, le Sat 30 Jan 2010 18:17:31 +0100, a écrit : > By the way, lstopo --whole-system fails on my dual-core machine when > core#1 is offline and debug is enabled: Indeed, in that case the Linux backend reports too big cpusets, I've added an automatic restriction to the existing PROC objects. Samuel
Re: [hwloc-devel] random api questions
Brice Goglin, le Sat 30 Jan 2010 18:17:31 +0100, a écrit : > Wait, does WHOLE_SYSTEM also toggle the ignoring of offline_cpus in > obj->cpuset? Yes, I believe it has always been that way. Samuel
Re: [hwloc-devel] random api questions
Brice Goglin, le Sat 30 Jan 2010 17:34:32 +0100, a écrit : > Most applications want the list of procs that are > online and allowed. So they'll have to compute the intersection of > online and allowed. I think it'd be better ot have "obj->cpuset" > contains this intersection. And rename the current "obj->cpuset" into > something like "obj->present_cpuset". (If the field eventually gets renamed, I'd rather call it topology_cpuset, as "present" doesn't say whether it's present in the topology or in the physical machine). Samuel
Re: [hwloc-devel] random api questions
Samuel Thibault wrote: > Yes, if we weren't wanting to express contradictory things it'd be way > simpler, but we want to. I don't believe duplicating information will > help the programmer to understand things. For now, I can see three > usage cases: > > - An application wants to bind itself somewhere. That's what the > default configuration is meant for. > > - A global monitoring application wants to check which processors are > online/allowed and where applications are running etc. That's what > the HWLOC_TOPOLOGY_FLAG_WHOLE_SYSTEM flag helps for. > Wait, does WHOLE_SYSTEM also toggle the ignoring of offline_cpus in obj->cpuset? The documentation doesn't say so, but the code seems to implement it. That would the best behavior. By the way, lstopo --whole-system fails on my dual-core machine when core#1 is offline and debug is enabled: Propagate total memory up 1853: hwloc__check_children: Assertion `hwloc_cpuset_iszero(remaining_parent_set)' failed. Brice
Re: [hwloc-devel] random api questions
Brice Goglin, le Sat 30 Jan 2010 17:40:29 +0100, a écrit : > Samuel Thibault wrote: > > Brice Goglin, le Sat 30 Jan 2010 17:34:32 +0100, a écrit : > > > >> But now that I understand all this, I wonder what application developers > >> will think about it. Most applications want the list of procs that are > >> online and allowed. > >> > > > > And that's what they already get by default unless they set the > > WHOLE_SYSTEM flag. > > r1711 says about obj->cpuset: > "They however may be offline, or not allowed for binding" I've added "if the WHOLE_SYSTEM flag is set"? Yes, if we weren't wanting to express contradictory things it'd be way simpler, but we want to. I don't believe duplicating information will help the programmer to understand things. For now, I can see three usage cases: - An application wants to bind itself somewhere. That's what the default configuration is meant for. - A user monitoring application wants to check where things are bound. The default configuration works for that too, provided it is started from the same environment. If not, an hwloc_topology_set_pid() configuration function is needed to get the proper restrictions. - A global monitoring application wants to check which processors are online/allowed and where applications are running etc. That's what the HWLOC_TOPOLOGY_FLAG_WHOLE_SYSTEM flag helps for. Samuel
Re: [hwloc-devel] random api questions
Samuel Thibault wrote: > Brice Goglin, le Sat 30 Jan 2010 17:34:32 +0100, a écrit : > >> But now that I understand all this, I wonder what application developers >> will think about it. Most applications want the list of procs that are >> online and allowed. >> > > And that's what they already get by default unless they set the > WHOLE_SYSTEM flag. > r1711 says about obj->cpuset: "They however may be offline, or not allowed for binding" Brice
Re: [hwloc-devel] random api questions
Brice Goglin, le Sat 30 Jan 2010 17:34:32 +0100, a écrit : > But now that I understand all this, I wonder what application developers > will think about it. Most applications want the list of procs that are > online and allowed. And that's what they already get by default unless they set the WHOLE_SYSTEM flag. Samuel
Re: [hwloc-devel] random api questions
Samuel Thibault wrote: > What about now (r1711)? > Yes, it's good now. But now that I understand all this, I wonder what application developers will think about it. Most applications want the list of procs that are online and allowed. So they'll have to compute the intersection of online and allowed. I think it'd be better ot have "obj->cpuset" contains this intersection. And rename the current "obj->cpuset" into something like "obj->present_cpuset". Brice
Re: [hwloc-devel] random api questions
Brice Goglin, le Sat 30 Jan 2010 17:05:29 +0100, a écrit : > >> What's the difference between obj->cpuset and the other obj->*cpuset ? > >> Some documentation is missing there, > >> > > > > Is the documentation on the right of the fields not sufficient? > > > > No at all... What about now (r1711)? Samuel
Re: [hwloc-devel] random api questions
Samuel Thibault wrote: > Brice Goglin, le Sat 30 Jan 2010 16:42:34 +0100, a écrit : > >> Do we want a #define HWLOC_API_VERSION to help people support both the >> 0.9 and the 1.0 APIs at runtime ? >> > > At build time you mean? > Yes. >> What's the difference between obj->cpuset and the other obj->*cpuset ? >> Some documentation is missing there, >> > > Is the documentation on the right of the fields not sufficient? > No at all... Brice
Re: [hwloc-devel] random api questions
Brice Goglin, le Sat 30 Jan 2010 16:42:34 +0100, a écrit : > Do we want a #define HWLOC_API_VERSION to help people support both the > 0.9 and the 1.0 APIs at runtime ? At build time you mean? > What's the difference between obj->cpuset and the other obj->*cpuset ? > Some documentation is missing there, Is the documentation on the right of the fields not sufficient? > and os_index should probably move outside of the list of *cpuset > fields. I guess with your memory changes we have already broken ABI compatibility anyway (I don't think we did before). We need to bump the soname accordingly. Samuel
[hwloc-devel] random api questions
Do we want a #define HWLOC_API_VERSION to help people support both the 0.9 and the 1.0 APIs at runtime ? What's the difference between obj->cpuset and the other obj->*cpuset ? Some documentation is missing there, and os_index should probably move outside of the list of *cpuset fields. /* FIXME: clarify what happens if ignoring the top-level type (ignore the ignoring?) */ HWLOC_DECLSPEC int hwloc_topology_ignore_type(hwloc_topology_t topology, hwloc_obj_type_t type); Brice