Creating nightly hwloc snapshot SVN tarball was a success.
Snapshot: hwloc 1.0a1r1721
Start time: Sat Jan 30 21:01:02 EST 2010
End time: Sat Jan 30 21:03:11 EST 2010
Your friendly daemon,
Cyrador
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
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 objec
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
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
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 som
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
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 alre
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
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 a
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
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 th
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
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: c
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 ins
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 allo
Brice Goglin, le Sat 30 Jan 2010 15:47:26 +0100, a écrit :
> 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
>
With p/l prefixes:
€ lstopo -p -
Machine(993MB) + Socketp0 + L2(2048KB)
L1(32KB) + Corep0 + Pp0
L1(32KB) + Corep1 + Pp1
€ lstopo -
Machine(993MB) + Socketl0 + L2l0(2048KB)
L1l0(32KB) + Corel0 + Pl0
L1l1(32KB) + Corel1 + Pl1
What I dislike is that this seems to bring odd words like "Corel"
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 topolo
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 administra
Samuel Thibault wrote:
> Brice Goglin, le Fri 29 Jan 2010 22:48:13 +0100, a écrit :
>
>> I am looking at the remaining tickets for v1.0. Assuming there are no
>> "critical" warning anymore, and assuming we have done enough for people
>> to combine network topologies (manually for now), only 2 ti
Brice Goglin, le Fri 29 Jan 2010 22:48:13 +0100, a écrit :
> I am looking at the remaining tickets for v1.0. Assuming there are no
> "critical" warning anymore, and assuming we have done enough for people
> to combine network topologies (manually for now), only 2 ticket remains:
> #12 support user-
22 matches
Mail list logo
