Re: [hwloc-devel] What's left for v0.9.1?

2009-09-14 Thread Brice Goglin
Jeff Squyres wrote: > Brice / Samuel -- > > What did you have planned left for hwloc v0.9.1? I think I got in all > the build system changes that I wanted for the time being (more coming > later, but not until after the first release). Should we SVN branch > for 0.9.1? > Nothing important on my

Re: [hwloc-devel] What's left for v0.9.1?

2009-09-14 Thread Brice Goglin
Jeff Squyres wrote: > On Sep 14, 2009, at 10:03 AM, Brice Goglin wrote: > >> > Does "make check" work properly? I.e., will it return pass/fail on >> > all the different platforms? >> >> It's supposed to be fully automake-compliant so I think s

[hwloc-devel] API, and make distcheck failure

2009-09-15 Thread Brice Goglin
Hello, I just gave a deep look and fixed several minor things in the API. The biggest thing I am not sure about is: We currently have several functions that may find something by type or by depth (for instance the number of objects, the n-th one, the next one, ...). These functions are currently

[hwloc-devel] last API possible changes

2009-09-17 Thread Brice Goglin
Hello, A couple other things that I am not sure about in the API: * In struct hwloc_topology_info, we talked about renaming "is_fake" into something else since it means "this topology does not come from the local machine" but it's not necessarily "fake". Any idea? * Do we actually need

Re: [hwloc-devel] New features or release?

2009-09-29 Thread Brice Goglin
Jeff Squyres wrote: > I see a bunch of new features being added to the hwloc trunk. > > Is the intent to stabilize the trunk and release, or is the intent to > add a bunch of PCI features before releasing? I kinda thought we were > trying to stabilize and release ASAP...? PCI stuff is going in

Re: [hwloc-devel] structure assumptions, duplication

2009-09-30 Thread Brice Goglin
Fawzi Mohamed wrote: > 1) a fully hierarchical representation of the machine/hardware where > each level is a partition, and each level fully covers the previous > one (from any node you go through all levels using father/childrens, > father/child are just one level away from each other.

Re: [hwloc-devel] structure assumptions, duplication

2009-09-30 Thread Brice Goglin
Fawzi Mohamed wrote: > NODE 1 > cache2 > cache1 > p0 > cache2 > cache1 > p1 > NODE 2 > cache1 > p2 > cache1 > p3 > > or is it even possible to have a node with children of a single node > of different depth? > > this is supposing that you want to keep

Re: [hwloc-devel] release status

2009-10-05 Thread Brice Goglin
Fawzi Mohamed wrote: > ok as I said to me it is not so strange (maybe init/clear would be a > better name though), but indeed it might confuse people, so probably > better avoid it. > Force the user to to the right thing is better. > > So the question remains, opaque + functions, or public... I

Re: [hwloc-devel] dynamic cpuset_t?

2009-10-07 Thread Brice Goglin
I just pushed a huge commit converting everything to dynamic cpusets. The new API is visable at https://svn.open-mpi.org/trac/hwloc/browser/trunk/include/hwloc/cpuset.h?rev=1109 The implementation is pretty much the same than our old inlines, see

Re: [hwloc-devel] dynamic cpuset_t?

2009-10-07 Thread Brice Goglin
Fawzi Mohamed wrote: > One comment, I see that you have a > hwloc_cpuset_copy (which I would have called duplicate) > but copy in the sense of assignment is not really possible (i.e. > reusing an existing allocated cpuset, and initialize it with the > content of another. I need to think

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r1119

2009-10-08 Thread Brice Goglin
Jeff Squyres wrote: > Is this what you had in mind? > > https://svn.open-mpi.org/trac/hwloc/changeset/1120 No, this removes sections 1 "hwloc" and 2 "glossary" (pages 10-22 of the PDF). These are generated from the doxy file. But the doxy file is also considered as a source/header file,

Re: [hwloc-devel] v0.9 branch

2009-10-21 Thread Brice Goglin
Jeff Squyres wrote: > On Oct 20, 2009, at 8:33 PM, Jeff Squyres wrote: > >> Brice -- do you need to move r1195 and r1196 to the v0.9 branch? > > I effectively just brought these over to the v0.9 branch. > > With all these changes, I'll cut an rc2 and post it shortly. Am I still supposed to make

Re: [hwloc-devel] v0.9 branch

2009-10-21 Thread Brice Goglin
, at 3:20 PM, Brice Goglin wrote: > >> Jeff Squyres wrote: >> > On Oct 20, 2009, at 8:33 PM, Jeff Squyres wrote: >> > >> >> Brice -- do you need to move r1195 and r1196 to the v0.9 branch? >> > >> > I effectively just brought these over to the v0

Re: [hwloc-devel] [hwloc] #21: Allow lookup of specific PIDs

2009-10-22 Thread Brice Goglin
Ashley Pittman wrote: > On Thu, 2009-10-22 at 13:48 +, hwloc wrote: > > >> Per discussion on the OMPI devel list, it would be useful to allow looking >> up topology information about specific PIDs (e.g., what cpuset they're >> bound to, etc.). >> >>

Re: [hwloc-devel] 0.9.1rc2 failures

2009-10-23 Thread Brice Goglin
Samuel Thibault wrote: >> topology-linux.c(787): remark #593: variable "proc_oscoreids" was set but >> never used >> unsigned proc_oscoreids[] = { [0 ... HWLOC_NBMAXCPUS-1] = -1 }; >> > > Heh, good catch. We indeed do not need it any more to manage the > computation. Brice, do you think

Re: [hwloc-devel] Priority of env vars vs. application options

2009-10-27 Thread Brice Goglin
Samuel Thibault wrote: > Hello, > > At the moment, the HWLOC_FSROOT and HWLOC_XMLFILE environment variables > override tool options and application configuration. Is it really the > behavior we should have? I'd tend to think that the priority order > should be: > > - application

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r1252

2009-10-29 Thread Brice Goglin
bgog...@osl.iu.edu wrote: > Author: bgoglin > Date: 2009-10-29 03:56:40 EDT (Thu, 29 Oct 2009) > New Revision: 1252 > URL: https://svn.open-mpi.org/trac/hwloc/changeset/1252 > > Log: > pciutils only got a .pc recently (in 2.2.6), so add configure code to > manually check for its headers and

Re: [hwloc-devel] hwloc-0.9.1rc3 fails with pgcc

2009-10-29 Thread Brice Goglin
What's in /radix-homes/software/com/packages/pgi-9.0-4/linux86-64/9.0-4/include/sched.h ? Brice

Re: [hwloc-devel] hwloc-0.9.1rc3 fails with pgcc

2009-10-29 Thread Brice Goglin
Do we support broken compilers ? :) Is this pgcc old? Is it supposed to work with a recent glibc that defines CPU* using __CPU*_S instead of using __CPU*? I don't know what they're doing, but the macros in this file look obsolete to me... Brice

Re: [hwloc-devel] docs updated

2009-10-29 Thread Brice Goglin
Jeff Squyres wrote: > It strikes me that Friday is a terrible day to release software. > > Should we just wait and release it Monday? (or Sunday night?) I don't care about the position of the stars :) Friday is actually a good day to release software: if anybody finds a big bug, you get 2 more

Re: [hwloc-devel] Pgcc issues fixed?

2009-11-04 Thread Brice Goglin
I think pgcc building fine was the last possible problem, so I assume everything is ok now. Brice Jeff Squyres wrote: > K. Clear for a final rc / release? > > (due to timezone differences, I'm going to assume yes -- I'll make an > rc now and if all goes well, let's release tomorrow morning)

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r1286

2009-11-05 Thread Brice Goglin
Of course, this is a very minor problem that doesn't need a rc5 and doesn't prevent from releasing today. It's been a month and a half already, we really need this first hwloc release out of door now (I don't want to hear about Friday again :)) Brice bgog...@osl.iu.edu wrote: > Author: bgoglin

[hwloc-devel] towards PLPA-like API in 1.0

2009-11-05 Thread Brice Goglin
Hello, I've been looking at the PLPA API and here's what we could do to add a hwloc/plpa.h offering kind of the same features. * PLPA-like API is prefixed with hwloc_plpa_ and all functions get a new hwloc_topology_t parameter. The problematic ones are: + int

Re: [hwloc-devel] 0.9.1rc4 is out

2009-11-05 Thread Brice Goglin
Pavan Balaji wrote: > Sorry for going back-and-forth. I thought it was my error, but maybe it > isn't. A fresh svn checkout from > http://svn.open-mpi.org/svn/hwloc/tags/hwloc-v0.9.2 gives the error I > mentioned. > > Am I missing something? > What if you use the regular autoconf instead of

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-11-09 Thread Brice Goglin
Brice Goglin wrote: > * Probing > > >From what I understand, plpa_have_topology_information() tells whether > PLPA knows what's in the hardware, while plpa_api_probe() tells whether > binding is supported. We could add: > > + hwloc_topology_support(hwloc_topology_t top

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r1333

2009-11-11 Thread Brice Goglin
Samuel Thibault wrote: > bgog...@osl.iu.edu, le Wed 11 Nov 2009 11:33:31 -0500, a écrit : > >> +/** \brief Bind thread given by \p pid to CPU set \p cpuset. >> + * >> + * \note This function now manipulates hwloc cpusets. >> + */ >> +static __inline int >>

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-11-12 Thread Brice Goglin
Jeff Squyres wrote: >> * PLPA-like API is prefixed with hwloc_plpa_ and all functions get a new >> hwloc_topology_t parameter. The problematic ones are: >> >> + int hwloc_plpa_sched_getaffinity(pid_t pid, hwloc_cpuset_t cpuset); >> > > Hmm. I'm a little confused. If we don't provide a drop-in

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-11-12 Thread Brice Goglin
Jeff Squyres wrote: > On Nov 12, 2009, at 9:25 AM, Samuel Thibault wrote: > >> > > There's certainly some desirable PLPA API features that could be >> > > imported to the HWLOC API -- but I would think that if people >> want to >> > > keep using the PLPA API, they can. It just won't [ever] be

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-11-12 Thread Brice Goglin
Jeff Squyres wrote: > Sorry for the delay in replying to this; been caught up in SC09 prep... Next time, I'll commit immediately instead of waiting for a week in case somebody ever reads my emails :) Brice

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-11-12 Thread Brice Goglin
Jeff Squyres wrote: >> Well, the list of good ideas will be very short then :) Most remaining >> functions are about manipulating core and socket ids, we don't need that >> at all in hwloc anymore. > > FWIW, having a "simple" API like that might be a Good Thing...? > > I.e., just be able to bind

[hwloc-devel] hwloc at SC09

2009-11-12 Thread Brice Goglin
FWIW, I'll be at SC09 next week, mostly on INRIA Booth #1405. I'll present hwloc (among other software we develop here). I'll have a USB key with lstopo static binaries (from the libpci branch) so that people can run it on their machine immediately. I hope somebody will show up with a 192-core

Re: [hwloc-devel] hwloc at SC09

2009-11-12 Thread Brice Goglin
Samuel Thibault wrote: > Ashley Pittman, le Thu 12 Nov 2009 19:11:11 +, a écrit : > >> I just tried to run it on my arm but failed as I only have autoconf >> 2.61, >> > > You can run ./configure && make dist on another machine to get an > autoconfied tarball ready to unpack/conf/make.

Re: [hwloc-devel] hwloc in Debian, anybody working on RPMs?

2009-11-20 Thread Brice Goglin
Tony Breeds wrote: > I have he beginings of a Fedora package. > > Using the 0.9.2 tarball the version on the .so is "0.0.0". This doesn't seem > "right". I'm happy to code up the libtool fu to make the so version match the > package version but is that what we want? I don't really expect that

Re: [hwloc-devel] Crash with ignoring HWLOC_OBJ_NODE in 0.9.2

2009-11-20 Thread Brice Goglin
Michael Raymond wrote: > Our architecture has blades with two Nehalems on them, and the blades > are connected together in a CC-NUMA fashion. Each Nehalem shows up as a > Node and the blades show up as Miscs. So you're running on the Altix UV with Nehalem-EX that SGI announced at SC? Is there

[hwloc-devel] PCI discovery for MacOSX

2009-11-24 Thread Brice Goglin
Hello, The current libpci branch uses the pciutils library (/usr/lib/libpci*.so*) to discover the hierarchy of PCI bridges/devices. pciutils works on many platforms, including windows (even if I never actually tried it). Unfortunately, there is no official support for MacOSX. I tried libpciaccess

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-12-02 Thread Brice Goglin
Brice Goglin wrote: > Jeff Squyres wrote: > >> FWIW, having a "simple" API like that might be a Good Thing...? >> >> I.e., just be able to bind to a specific thread/core/socket with a >> minimum fuss/muss. Even if such an API would be mainly syntacti

Re: [hwloc-devel] hwloc-bind syntax

2009-12-03 Thread Brice Goglin
Jeff Squyres wrote: > I was trying to use hwloc-bind this morning, and I was a bit confused by the > syntax. I see that the help message says: > > - > Usage: topobind [options] -- command ... > may be a space-separated list of cpusets or objects > as supported by the

Re: [hwloc-devel] hwloc-bind syntax

2009-12-03 Thread Brice Goglin
Jeff Squyres wrote: > I haven't looked at the argv parsing -- does it just strcmp each of the > argv's and look for a recognized prefix, and if so, assume that it is a > specification? If it doesn't find a recognized prefix, it assumes that it's > the first argv of the tokens to exec (and

Re: [hwloc-devel] hwloc-bind again

2009-12-04 Thread Brice Goglin
Jeff Squyres wrote: > I notice that > > shell$ hwloc-bind > > (i.e., invoking hwloc-bind with no arguments) > > returns an exit status of 0. Shouldn't it return non-zero? I'd think it was > an error if you didn't give hwloc-bind anything to do. For example, we > wouldn't want a script with

Re: [hwloc-devel] hwloc-bind syntax

2009-12-04 Thread Brice Goglin
Jeff Squyres wrote: > It might be good to safely ignore 0x if it's present, but that's a small > feature enhancement that can be done at any time (I filed a future ticket). > It seems to work actually :) >> We might want to drop the Linux "cpuset" word and use "cgroup" instead. >> Both are

Re: [hwloc-devel] Disabling X component

2009-12-04 Thread Brice Goglin
Ashley Pittman wrote: > I installed the debian package of hwloc yesterday and discovered that > the default action of lstopo is to display a window with a picture in. > I guess I don't have the right development packages installed for this > to be enabled in my local build. > > In my tool I want

Re: [hwloc-devel] embedding m4 code

2009-12-05 Thread Brice Goglin
Jeff Squyres wrote: > I think I have the first part of the embedding code done -- it builds and > compiles hwloc just like today's build system does (but a bunch of the m4 > behind the scenes has moved around quite a bit to enable the embedding > stuff). :-) > > Could you guys try builds on

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r1447

2009-12-08 Thread Brice Goglin
jsquy...@osl.iu.edu wrote: > Author: jsquyres > Date: 2009-12-08 13:15:03 EST (Tue, 08 Dec 2009) > New Revision: 1447 > URL: https://svn.open-mpi.org/trac/hwloc/changeset/1447 > > Log: > New require LT 2.2.6b > By the way, isn't LT_INIT supposed to enforce the required version? We had a bug

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r1447

2009-12-08 Thread Brice Goglin
Brice Goglin wrote: > Jeff Squyres wrote: > >> On Dec 8, 2009, at 1:23 PM, Brice Goglin wrote: >> >> >> >>> We already have >>> LT_PREREQ([2.2.6]) >>> LT_INIT >>> It doesn't seem to actually enforce libtool >= 2.2.

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r1447

2009-12-08 Thread Brice Goglin
figure: line 7566: syntax error near unexpected token `2.2.6' ../gitsrc/configure: line 7566: `LT_PREREQ(2.2.6)' > On Dec 8, 2009, at 1:41 PM, Brice Goglin wrote: > > >> Brice Goglin wrote: >> >>> Jeff Squyres wrote: >>> >>>

Re: [hwloc-devel] test failure

2009-12-09 Thread Brice Goglin
Jeff Squyres wrote: > While working on the embedded stuff, I noticed the following assertion > failure in the SVN trunk: > > lt-hwloc_cpuset_string: hwloc_cpuset_string.c:110: main: Assertion > `hwloc_cpuset_isequal(set, obj->cpuset)' failed. > /bin/sh: line 1: 10909 Aborted

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-12-10 Thread Brice Goglin
Brice Goglin wrote: >> I am looking at what we could add to the main API/helpers, here's what >> could be useful: >> 1) get_obj_under_by_type(topology, type, index, subtype, subindex) >> returns for instance core 2 under socket 3. It's very easy >> (get_obj_by_type

Re: [hwloc-devel] towards PLPA-like API in 1.0

2009-12-10 Thread Brice Goglin
Jeff Squyres wrote: >> and Jeff has already removed the PLPA tests from >> trunk, I am going to add (1) and probably (3), and document (2) and (4) >> in the PLPA doc section. Then I'll move most comments from plpa.h into >> this doc section and remove plpa.h entirely. >> > > How about having

Re: [hwloc-devel] v1.0 features

2009-12-14 Thread Brice Goglin
Jeff Squyres wrote: > So where do we want to draw the line for v1.0? > > Due to some external forces, it may be desirable to get hwloc embedded in > Open MPI sooner rather than later. We can take a beta/snapshot of hwloc in > Open MPI, but it would always be nicer to take an officially released

Re: [hwloc-devel] embedding next step

2009-12-15 Thread Brice Goglin
Jeff Squyres wrote: > Instead of using PLPA-style macros to rename the symbols throughout the > source code, I introduced that, if renaming is enabled, will > #define hwloc_foo to _foo. > > I only did a handful of names so far just to prove that it was working: > > #define hwloc_cpuset_alloc

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r1466

2009-12-16 Thread Brice Goglin
jsquy...@osl.iu.edu wrote: > Add bullet about the compar -> compare rename > > Text files modified: >trunk/NEWS | 3 +++ >1 files changed, 3 insertions(+), 0 deletions(-) > > Modified: trunk/NEWS >

Re: [hwloc-devel] #23: network topology support and v1.0 semantic fixes

2010-01-07 Thread Brice Goglin
Samuel Thibault wrote: > Now, coming to semantic changes: > - The top node of the tree wouldn't necessarily be a system object. > Actually, having always the top object having the system type is not > providing any useful information :) And having the root object type vary from machine to

Re: [hwloc-devel] "file name is too long" error during make distwith libpci branch

2010-01-08 Thread Brice Goglin
Jeff Squyres wrote: > On Jan 6, 2010, at 3:26 PM, Samuel Thibault wrote: > > >> Cédric Augonnet, le Wed 06 Jan 2010 21:20:48 +0100, a écrit : >> >>> tar: >>>

Re: [hwloc-devel] "file name is too long" error during make distwith libpci branch

2010-01-11 Thread Brice Goglin
Jeff Squyres wrote: > I don't think we should let doxygen dictate the code that we write. Agreed. Headers are already kind of the horrible :) > 1. make doxy do what we want > Setting SHORT_NAMES to YES in doxygen.cfg seems to help. html and latex filenames are replaced with things like

Re: [hwloc-devel] "file name is too long" error during make dist with libpci branch

2010-01-12 Thread Brice Goglin
I've committed the fixes to trunk. Visible changes include: no latex files in the tarball anymore, and shorter names for html pages. Cedric's warnings were only in the libpci branch, they are gone now, but I won't commit the update of the branch before later today in case somebody wants to

[hwloc-devel] parent vs father

2010-01-16 Thread Brice Goglin
Jeff Squyres wrote: >> I am not sure. The object structure contains a father pointer. We use >> parent in the API, but it might refer to different things, like father, >> grandfather, ... >> > > FWIW, the english word "parent" definitely refers to the immediate ancestor. > It does *not*

Re: [hwloc-devel] memory size attributes

2010-01-16 Thread Brice Goglin
Brice Goglin wrote: > Hello, > > While cleaning the System/Machine root types, I wondered what we > actually want to store in memory_kB attributes. It looks obvious for > Caches and NUMA nodes. But I am not sure about Machines and Systems. > > If we have a machine with

Re: [hwloc-devel] memory size attributes

2010-01-17 Thread Brice Goglin
Jeff Squyres (jsquyres) wrote: > > Just so I understand - are you saying hwloc should track both the > total amount of memory *and* the makeup of that amount, broken up by > page size? > I don't know if we need this. Right now we have total amount + number of hugepages + size of hugepages. I was

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r1664

2010-01-25 Thread Brice Goglin
Jeff Squyres wrote: > Ick! > > Does this mean that some versions of doxy have this bug and some don't? > I don't think we used \page in 0.9 so we probably never tested this bug before I switched glossary/tools/envvar/plpa/embed to \plpa about a month ago. The bug occurs with doxygen 1.6.2

Re: [hwloc-devel] memory size attributes

2010-01-26 Thread Brice Goglin
I have pushed some changes in the memoryattrs branch. See the new memory attributes starting at line 138 of https://svn.open-mpi.org/trac/hwloc/browser/branches/memoryattrs/include/hwloc.h I am still working on the XML backend. It'd be good if people could complain about the API before I convert

Re: [hwloc-devel] memory size attributes

2010-01-27 Thread Brice Goglin
I pushed the last bunch of changes to the memoryattrs branch. I don't plan any other changes about this. I'll probably merge into trunk by the end of the week unless somebody complains ;) Brice

Re: [hwloc-devel] P#0 -> P0 for logical numbers?

2010-01-28 Thread Brice Goglin
Jeff Squyres wrote: > On Jan 28, 2010, at 9:05 AM, Samuel Thibault wrote: > > >> Since we changed the default behavior of lstopo to display logical >> numbers instead of physical numbers, I've quite a few times taken one >> for the other, leading to confusion. >> > > Mmm... good point. > >

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r1709

2010-01-29 Thread Brice Goglin
Jeff Squyres wrote: > Why put it into the Attic? This isn't CVS. :-) > > If you "svn rm" something, it stays in the history forever. > It's smoehow a special tag marking the end of a branch. See "attic/foo" as a short replacement for "hwloc/tags/old-foo-branch-that's-closed-now". Not very

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r1709

2010-01-29 Thread Brice Goglin
Jeff Squyres wrote: > On Jan 29, 2010, at 4:03 PM, Brice Goglin wrote: > > >> It's smoehow a special tag marking the end of a branch. See "attic/foo" >> as a short replacement for >> "hwloc/tags/old-foo-branch-that's-closed-now". Not very useful,

[hwloc-devel] processor restriction + lookup of pid for 1.0

2010-01-29 Thread Brice Goglin
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-defined processor restriction #21 Allow lookup of specific PIDs I

Re: [hwloc-devel] processor restriction + lookup of pid for 1.0

2010-01-30 Thread Brice Goglin
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 th

Re: [hwloc-devel] random api questions

2010-01-30 Thread Brice Goglin
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. >> Wh

Re: [hwloc-devel] random api questions

2010-01-30 Thread Brice Goglin
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

Re: [hwloc-devel] random api questions

2010-01-30 Thread Brice Goglin
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. >

Re: [hwloc-devel] random api questions

2010-01-30 Thread Brice Goglin
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

Re: [hwloc-devel] [hwloc] #12: support user-defined processor restriction

2010-02-15 Thread Brice Goglin
hwloc wrote: > 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

[hwloc-devel] hwloc in mvapich2

2010-02-23 Thread Brice Goglin
mvapich2 trunk and 1.4 branches now support hwloc: http://mail.cse.ohio-state.edu/pipermail/mvapich-commit/2010-February/001224.html Brice

[hwloc-devel] 1.0-rc1

2010-02-26 Thread Brice Goglin
Are we doing a 1.0-rc1 soon ? The only things I see in my TODOlist are: * cleanup allowed_nodeset on Linux so that it only contains existing nodes (it's a *full* cpuset right now, which looks ugly in XML exports :)) * ticket #12 "support user-defined processor restriction" might wait for 1.1 or

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r1773

2010-02-26 Thread Brice Goglin
jsquy...@osl.iu.edu wrote: > +$(SYMLINKED_SOURCES): > + if test ! -r $@ ; then \ > + $(LN_S) $(SRC)/$@ $(HWLOC_top_srcdir)/tests/ports/$@; \ > + fi > Random question: could we use AC_CONFIG_LINKS for this ? Brice

Re: [hwloc-devel] 1.0-rc1

2010-03-03 Thread Brice Goglin
Brice Goglin wrote: >> What hasn't been finished yet and to my opinion needs to be for v1.0, is >> the prefix/suffix/whatever to easily distinguish between physical and >> logical numbers in lstopo. >> > > I played with this today and arrived to these con

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r1795

2010-03-04 Thread Brice Goglin
jsquy...@osl.iu.edu wrote: > Author: jsquyres > Date: 2010-03-01 20:56:14 EST (Mon, 01 Mar 2010) > New Revision: 1795 > URL: https://svn.open-mpi.org/trac/hwloc/changeset/1795 > > Log: > Fix a bunch of small errors: > > * Ensure the srcdir gets the right value > * Convert some more "if test..."

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r1809

2010-03-07 Thread Brice Goglin
bgog...@osl.iu.edu wrote: > Author: bgoglin > Date: 2010-03-07 13:38:39 EST (Sun, 07 Mar 2010) > New Revision: 1809 > URL: https://svn.open-mpi.org/trac/hwloc/changeset/1809 > > Log: > hwloc-mask: display physical indexes for --proc/nodelist if --physical is > given > I wonder if we should

Re: [hwloc-devel] Why are misc objects ignored by default?

2010-03-10 Thread Brice Goglin
Samuel Thibault wrote: > Hello, > > In hwloc_topology_init(), topology->ignored_types[HWLOC_OBJ_MISC] is set > to HWLOC_IGNORE_TYPE_KEEP_STRUCTURE by default. Is there a reason for > it? The problem is that there is no option to change that... > > Samuel > commit

Re: [hwloc-devel] Why are misc objects ignored by default?

2010-03-10 Thread Brice Goglin
Samuel Thibault wrote: >> I guess what we called "Fake" or "Misc" has evolved a bit. In the >> beginning, it was more some "strange" stuff that could be ignored if it >> didn't bring any new structure. Now it's more about "misc" stuff for real. >> > > Mmm, well, the code hasn't changed, now I

Re: [hwloc-devel] [PATCH] Use the #links as an estimate for the #tids in a tasks directory

2010-03-11 Thread Brice Goglin
Applied thanks! Brice Bert Wesarg wrote: > When reading all tids from a process in > topology-linux.c::hwloc_linux_get_proc_tids(), it used a > exponential realloc algorithm to increase the storage size for the tids. > > Now it uses the number of links (.st_nlinks) from a stat() call to the >

Re: [hwloc-devel] [PATCH] Use getmntent_r(3) to parse /proc/mounts lines

2010-03-11 Thread Brice Goglin
Bert Wesarg wrote: > This does multiple things at once: > > I) it uses getmntent_r(3) to parse lines from /proc/mounts > > II) while doing this, it uses the correct un-escape rules for this > file format. > > The current code converts "\ " to " ", while linux uses a "\040" to > "

Re: [hwloc-devel] thread safety

2010-03-12 Thread Brice Goglin
Jeff Squyres wrote: > 1. thread A calls hwloc_topology_init() > 2. thread A calls hwloc_topology_load(a) > 3. thread A launches thread B > 4. thread B calls hwloc_topology_get_*(a...) > 5. thread A calls hwloc_topology_load(a) > > On the one hand, you could say that an app would be dumb to do

Re: [hwloc-devel] [PATCH] Use getmntent_r(3) to parse /proc/mounts lines

2010-03-12 Thread Brice Goglin
Bert Wesarg wrote: >> Ups, what about the fsroot_fd now? I think this has something to do if >> /proc and /sys are not mounted at the root, for example in test mode, >> right? >> > > I'm right. The only way out I see is to step aside from openat and use > string operations to for this. > > I

Re: [hwloc-devel] [PATCH 2/2] Provide hwloc_cpuset_next() and use it in hwloc_cpuset_foreach

2010-03-12 Thread Brice Goglin
Bert Wesarg wrote: > The hwloc_cpuset_next() will calculate the next cpu behind a given one. > > Use hwloc_cpuset_first() and hwloc_cpuset_next() in hwloc_cpuset_foreach() > to sparsely iterate over a cpuset. > Applied both patches, thanks. Brice

Re: [hwloc-devel] [PATCH] Avoid expensive ffsl/flsl calls in cpuset operations

2010-03-15 Thread Brice Goglin
Applied, thanks!

Re: [hwloc-devel] Proposal for cpuset API change

2010-03-17 Thread Brice GOGLIN
> Hi, > > I think it is necessary to make a small change to the cpuset API. The > current API was made fit to allow dynamically sized cpusets. I.e. an > alloc/modify/free style life cycle. The problem I see is, from where > should hwloc_cpuset_alloc() get the size of the cpuset? The solution I >

Re: [hwloc-devel] [PATCH] Replace readdir() with readdir_r()

2010-03-18 Thread Brice Goglin
Bert Wesarg wrote: > Make the linux backend more re-entrant safe by using readdir_r() instead > of readdir(). > Changing so many lines because of bugs that don't exist yet doesn't look like a good idea to me. If we ever want to parallelize the bottom of the discovery stack (or whatever needs

Re: [hwloc-devel] [PATCH] Replace readdir() with readdir_r()

2010-03-18 Thread Brice Goglin
Samuel Thibault wrote: > Brice Goglin, le Thu 18 Mar 2010 22:58:35 +0100, a écrit : > >> Bert Wesarg wrote: >> >>> Make the linux backend more re-entrant safe by using readdir_r() instead >>> of readdir(). >>> >> Changing so many

Re: [hwloc-devel] 1.0-rc1

2010-03-25 Thread Brice Goglin
Bert Wesarg wrote: > On Mon, Mar 22, 2010 at 21:29, Brice Goglin <brice.gog...@inria.fr> wrote: > >> Brice Goglin wrote: >> >>> Are we doing a 1.0-rc1 soon ? >>> >>> >> Same question again :) >> > > I

Re: [hwloc-devel] 1.0-rc1

2010-03-26 Thread Brice Goglin
Samuel Thibault wrote: > Jeff Squyres, le Fri 26 Mar 2010 07:50:34 -0400, a écrit : > >> I think once we fix up this attribute stuff that Bert raised we should make >> rc1. >> > > We still haven't decided what to do for printing logical vs physical > numbers in lstopo. > We already

Re: [hwloc-devel] Strange difference

2010-03-26 Thread Brice Goglin
Jeff Squyres wrote: > On Mar 26, 2010, at 11:33 AM, Samuel Thibault wrote: > > >> Well, yes, it is supposed to display less information :) >> Which precise difference are you referring to? >> > > The first section of both -- obviously, not the 2nd section of the -v output. > :-) > > The

Re: [hwloc-devel] Strange difference

2010-03-26 Thread Brice Goglin
Jeff Squyres wrote: > On Mar 26, 2010, at 5:20 PM, Samuel Thibault wrote: > > >> That's still very large. We are going toward dozens of cores on each >> sockets, we really need to keep them small :) >> > > Fair enough. How about still just keeping "P" in the graphic output, then? > But

Re: [hwloc-devel] Strange difference

2010-03-30 Thread Brice Goglin
Chris Samuel wrote: > On Sat, 27 Mar 2010 05:15:50 am Jeff Squyres wrote: > > >> At least on my machine, the output width is still far less than 80 >> characters, so the full word should be no problem. But I don't know if >> there are other strange topologies out there that would take up more

Re: [hwloc-devel] Strange difference

2010-03-31 Thread Brice Goglin
Jeff Squyres wrote: > Is it a crime to use the full word "Processor"? At least on my machine, the > output width is still far less than 80 characters, so the full word should be > no problem. But I don't know if there are other strange topologies out there > that would take up more space...?

Re: [hwloc-devel] rc1?

2010-04-01 Thread Brice Goglin
Jeff Squyres wrote: > There have been a few commits today -- are we ready for rc1? Give me the > word and I'll make it. :-) > I am done now (r1895). Brice

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r1896

2010-04-01 Thread Brice Goglin
Yes, it's fixed in 1.6.3. Brice Jeff Squyres wrote: > Has this bug been reported upstream to the doxygen people? > > The thread safety section wasn't showing up in the PDF this afternoon; it > confounded me for an hour before I stumbled across this workaround in the > Makefile.am. > > > On

Re: [hwloc-devel] rc1?

2010-04-03 Thread Brice Goglin
Samuel Thibault wrote: > Brice Goglin, le Thu 01 Apr 2010 19:13:23 +0200, a écrit : > >> Jeff Squyres wrote: >> >>> There have been a few commits today -- are we ready for rc1? Give me the >>> word and I'll make it. :-) >>> >>

Re: [hwloc-devel] rc1?

2010-04-06 Thread Brice Goglin
Jeff Squyres wrote: > On Apr 3, 2010, at 6:32 PM, Brice Goglin wrote: > > >> By the way, instead of delaying the release while we discuss this and >> wait for your fix, we could mark hwloc_topology_insert_misc*() as >> experimental or even undocument it for now,

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r1960

2010-04-20 Thread Brice Goglin
I do git cherry-pick -e master and git svn dcommit :) Brice Jeff Squyres wrote: > Done. BTW, I use the attached helper script to merge stuff in to the > branches (can't remember if I've sent this before or not). It's a trivial > thing, but it reduces the amount of stuff I have to type on

[hwloc-devel] dplace

2010-04-20 Thread Brice Goglin
I discovered "dplace" today. I don't know how many people install/use it on their cluster, but it's something that looks interesting when you don't have advanced binding capabilities in the MPI implementation. For instance, you could do: $ mpirun -np 8 dplace 0,4,2,6,1,5,3,7 myprogram to bind

  1   2   3   4   5   6   7   8   >