Jeff Squyres, le Fri 26 Mar 2010 12:51:53 -0400, a écrit :
> Does this work with compilers that (pseudo) impersonate gcc (e.g., icc)?
Yes.
Samuel
Jeff Squyres, le Fri 26 Mar 2010 14:15:50 -0400, a écrit :
> On Mar 26, 2010, at 2:01 PM, Brice Goglin wrote:
>
> > > I like "Proc" instead of "P" even for the non-v output. :-)
> >
> > I am not against it, but I don't remember the reason for the initial
> > change. Maybe because "processor" is
Bert Wesarg, le Fri 26 Mar 2010 19:39:51 +0100, a écrit :
> On Fri, Mar 26, 2010 at 17:01, Samuel Thibault <samuel.thiba...@inria.fr>
> wrote:
> > Thanks for the idea.
> >
> > Bert Wesarg, le Fri 26 Mar 2010 12:33:00 +0100, a écrit :
> >> +#define HWLO
Jeff Squyres, le Fri 26 Mar 2010 17:05:39 -0400, a écrit :
> On Mar 26, 2010, at 4:16 PM, Samuel Thibault 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 characte
Bert Wesarg, le Sat 27 Mar 2010 15:06:43 +0100, a écrit :
> > + if (needed_count <= ulongs_count)
> > + return;
> > +
> > + while (ulongs_count < needed_count)
> > + ulongs_count *= 2;
Mmm, this is actually 1 << (hwloc_fls(needed_count)), isn't it?
SAmuel
Brice Goglin, le Wed 31 Mar 2010 11:37:17 +0200, a écrit :
> We might need to replace some occurences of "logical processor" in the
> doc with "processing unit". Or use both from time to time to make it
> clear that it's very similar (and explain the difference somewhere).
I'd say keep it in the
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. :-)
>
> I am done now (r1895).
I'd like to fix the MISC objects so they are not ignored.
Samuel, hates
Fawzi Mohamed, le Fri 02 Apr 2010 17:34:20 +0200, a écrit :
> would be fine with me, planning to add al lot of flags? because there
> is still lot of space to grow (and one can later switch to 64 bit... :)
Just switching to 64bits would break the ABI. It's better to just use
chars and be done
Jeff Squyres, le Fri 02 Apr 2010 12:32:35 -0400, a écrit :
> But to use an external PLPA/libltdl/whatever, OMPI's configure would just
> call their configure
?!
I'm not 100% sure what RedHat etc. do, but in Debian the policy wouldn't
be to do this, but to just link against the existing
Brice Goglin, le Sun 04 Apr 2010 00:32:24 +0200, a écrit :
> As I said in the past, we're trying to address 2
> different issues. I said we could have a "Group" type to replace the
> current meaning of "Misc" and keep "Misc" for user-added objects only.
That's what I meant by "fixing" misc
Brice Goglin, le Sun 04 Apr 2010 17:11:36 +0200, a écrit :
> So, do we want something like:
> 1) insert_misc_by_cpuset() to always insert below objects with same cpusets?
> Might be better for some use cases, and worse for others...
Having one default would be easy, it's just a matter of
Jeff Squyres, le Fri 02 Apr 2010 14:51:06 -0400, a écrit :
> On Apr 2, 2010, at 2:25 PM, Samuel Thibault wrote:
>
> > > But to use an external PLPA/libltdl/whatever, OMPI's configure would just
> > > call their configure
> >
> > I'm not 100% sure what RedH
Jeff Squyres, le Tue 06 Apr 2010 09:05:24 -0400, a écrit :
> On Apr 4, 2010, at 12:15 PM, Samuel Thibault wrote:
> > Why
> > is it so? Can't the main ./configure call the hwloc m4 stuff or not
> > depending on whether the internal or the external version is used?
>
Jeff Squyres, le Tue 06 Apr 2010 18:05:03 -0400, a écrit :
> > So I still don't see why going back to ./configure instead of using m4.
>
> Mainly because:
>
> 1. The potential for maintenance difficulties in the future.
> 2. I don't (offhand) know of anyone outside of Open MPI who would use the
Just to make it clear: I'm done concerning 1.0 features.
Samuel
Fawzi Mohamed, le Wed 14 Apr 2010 14:05:45 +0200, a écrit :
> HWLOC_OBJ_GROUP
>
> I suppose that those groups still form a partition,
Yes.
> I know that was changed also due to my comments, but I am not sure the
> change really better: the structure is not really hidden, so adding a
> flags
Bert Wesarg, le Tue 20 Apr 2010 17:55:10 +0200, a écrit :
> > +#define GNU_SOURCE
>
> That should be: _GNU_SOURCE.
Oops, typo indeed, thanks for the proofread.
Samuel
Brice Goglin, le Tue 20 Apr 2010 19:54:13 +0200, a écrit :
> I tend to think that we should just drop the get_system_obj() and make
> it clear that people have to fix everything, not everything except foo
> and bar.
I'd tend to agree. We should however mention the previous names in the
Jeff Squyres, le Wed 21 Apr 2010 09:04:11 -0400, a écrit :
> On Apr 21, 2010, at 8:47 AM, Bert Wesarg wrote:
>
> > From that page:
> >
> > If you are writing a header file that must work when included in
> > ISO C programs, write __typeof__ instead of typeof. See Alternate
> > Keywords.
> >
Jeff Squyres, le Mon 03 May 2010 09:28:41 -0400, a écrit :
> I see a flurry of windows-related activity over the weekend.
>
> Do you guys want me to cut rc4?
I'm done with what I wanted to fix in rc3.
Samuel
Jeff Squyres, le Mon 03 May 2010 09:57:09 -0400, a écrit :
> 1.0rc4 is up. Send me a windows binary when you get a chance.
http://dept-info.labri.fr/~thibault/tmp/hwloc-win32-build-1.0rc4.zip
Samuel
Jeff Squyres, le Mon 03 May 2010 15:57:37 -0500, a écrit :
> Running lstopo on w7 (64 bit):
>
> -
> C:\Temp\hwloc>lstopo
> Note: GetLogicalProcessorInformationEx was never tested yet!
> -
Ooops, it seems I have forgotten to remove it. Now done.
> Plus, the memory it reported was the
Brice Goglin, le Tue 04 May 2010 07:54:47 +0200, a écrit :
> line 41 of src/misc.c in hwloc_snprintf():
>
> str = malloc(size);
>
>
> I am not sure what to do about this one... Is there any value we could return
> without possibly breaking the caller ?
0 seems relatively safe to
bgog...@osl.iu.edu, le Tue 04 May 2010 01:32:00 -0400, a écrit :
> @@ -326,6 +330,10 @@
> if (nr_tids == max_tids) {
>max_tids += 8;
>tids = realloc(tids, max_tids*sizeof(pid_t));
> + if (!tids) {
> +errno = ENOMEM;
> +return -1;
> + }
> }
>
Jeff Squyres, le Thu 06 May 2010 08:17:53 -0400, a écrit :
> hwloc 1.0rc5 is posted. Hopefully it can be the last! :-)
>
> (Samuel -- can you make the windows binaries?)
http://dept-info.labri.fr/~thibault/tmp/hwloc-win32-build-1.0rc5.zip
Samuel
Jeff Squyres, le Thu 06 May 2010 13:39:43 -0400, a écrit :
> Did you want to get those warning fixes in to v1.0? (r2074 - 2076)
>
> Or are they trunk-only?
They concern rc5 as well, I'm just unsure they are really worth making
yet another RC, as they have no impact on the behavior of hwloc at
Pavan Balaji, le Mon 10 May 2010 20:56:19 -0500, a écrit :
> I understand that hwloc requires C99 support. However, for compilers
> that don't support C99, would you be willing to gracefully abort during
> configure instead of failing at make time?
Right, thanks.
Samuel
Jeff Squyres, le Wed 12 May 2010 12:52:01 -0400, a écrit :
> I just posted rc6 with the fixes for this.
I have built the windows binary, available on
http://dept-info.labri.fr/~thibault/tmp/hwloc-win32-build-1.0rc6.zip
Samuel
Good for me.
Samuel
Wheeler, Kyle Bruce, le Tue 25 May 2010 13:46:09 -0600, a écrit :
> I agree that, inherently, cache line size has nothing to do with topology.
> But on the other hand, it's particularly useful for parallel shared-memory
> applications (to avoid false-sharing),
The false-sharing part is where it
hwloc, le Thu 27 May 2010 21:06:56 -, a écrit :
> Anyone have any comments / suggestions about r2149 before I close this
> ticket and move it over to the v1.0 branch?
It looks good to me.
Samuel
Jeff Squyres, le Fri 28 May 2010 09:03:30 -0400, a écrit :
> On May 28, 2010, at 9:01 AM, Samuel Thibault wrote:
>
> > > ...actually, I'm not seeing where we use epstopdf in our build process...?
> >
> > I believe it's hidden somewhere in pdflatex or such call.
&g
bgog...@osl.iu.edu, le Fri 28 May 2010 11:27:47 -0400, a écrit :
> Add a backend info string, except in XML since we may not want to override
> the one that we got from the XML file
>
> + add_object_info(topology->levels[0][0], strdup("Backend=AIX"));
Mmm, this will probably need to be
Jeff Squyres, le Tue 01 Jun 2010 14:03:47 -0400, a écrit :
> So do we like 1.0.1rc1?
I haven't had the time to test it at all.
Samuel
Jeff Squyres, le Thu 03 Jun 2010 12:32:50 -0400, a écrit :
> Were you expecting all those solaris commits to the v1.0 tree to go into the
> v1.0.1 release? Or are those intended for 1.0.2?
Well, I see no reason not to put them in 1.0.1 actually :), except that
we need to test another rc. I'm
Jeff Squyres, le Thu 03 Jun 2010 15:02:35 -0400, a écrit :
> I think that hwloc's Libtool version number should go from 0:0:0 to 0:1:0.
>
> Can someone sanity check to ensure that's right?
I believe that's right.
Samuel
Jeff Squyres, le Fri 18 Jun 2010 06:56:59 -0700, a écrit :
> Just curious -- what's the intent of assigning to errno like this? (I ask
> because I thought that middleware/applications were not supposed to assign to
> errno)
To convert functions returning the error into our convention of
Hello,
I agree that rpath should be avoided. However, hwloc itself doesn't add
any.
Jirka Hladky, le Fri 18 Jun 2010 22:09:56 +0200, a écrit :
> =
> hwloc.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/hwloc-distrib
> ['/usr/lib64']
So
Samuel Thibault, le Sat 19 Jun 2010 00:03:49 +0200, a écrit :
> What is the output of gcc -print-search-dirs?
Ah, no, I misread the configure script, sys_lib_dlsearch_path_spec
comes from ld.so.conf (that makes sense actually). Could you post your
/etc/ld.so.conf (and any file that it co
Jeff Squyres, le Mon 21 Jun 2010 10:48:13 -0400, a écrit :
> I still see -rpath being inserted in the final link step for libhwloc.so (SVN
> build using AC 2.65, AM 1.11.1, LT 2.2.6b):
>
> /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99
> -fvisibility=hidden -I/usr/include/libxml2
Hello,
Jirka Hladky, le Mon 21 Jun 2010 18:54:47 +0200, a écrit :
> I don't have "/usr/lib64" directory listed in
> /etc/ld.so.conf. However, "/usr/lib64" is considered to be the
> default lib location on 64-bit system.
Ok. And
James Laska, le Mon 21 Jun 2010 13:15:36 -0400, a écrit :
> To note, if I understand correctly, adding '/usr/lib64'
> to /etc/ld.so.conf or /etc/ld.so.conf.d/* should not be needed.
I agree.
> Anything in the standard Fedora library locations should be recognized
> and not require an additional
Jirka Hladky, le Mon 21 Jun 2010 22:30:36 +0200, a écrit :
> I'm not sure what's wrong. It seems like libtool is not smart enough to
> recognize /usr/lib64 as default library directory on 64-bit system
Well, on Debian it's not needed (and might even be harmful).
Samuel
Thanks for your work!
Samuel
Samuel Thibault, le Thu 24 Jun 2010 18:28:18 +0200, a écrit :
> > depending on the type of machine you're running on.
>
> It also depends on the OS and kernel version for instance. Not all
> information is available, the only you can bet on is PUs under a system
> object. At w
Jeff Squyres, le Fri 25 Jun 2010 09:50:05 -0400, a écrit :
> Sounds like this is just a doc bug, right? If so, I can fix.
Probably, yes, please do.
Samuel
Jeff Squyres, le Fri 25 Jun 2010 10:03:10 -0400, a écrit :
> While I'm updating the docs in this area, can you guys send XML output for
> dudley, hagrid, and emmett?
Here they are.
Samuel
Jeff Squyres, le Fri 25 Jun 2010 10:46:59 -0400, a écrit :
> Before I do the other two, how does this look, formatting-wise? (see
> attached)
This looks good to me.
Samuel
Hello Jorge,
I've just noticed Servet in the ipdps 2010 proceedings. There
are probably interesting things to do between Servet and hwloc
http://www.open-mpi.org/projects/hwloc/
On one hand, servet could use hwloc to get binding implementations
on various OSes. Indeed, Servet version 1.0
Jeff Squyres, le Fri 25 Jun 2010 12:13:22 -0400, a écrit :
> It's unfortunate that the PPC64 SMT image is so tall; it makes weird vertical
> gaps on the prior page. :-\
Maybe you can output to xml, strip half of the numa nodes, and re-render
it. That's want I actually do for Hagrid.
Samuel
Jeff Squyres, le Fri 25 Jun 2010 12:13:22 -0400, a écrit :
> Rather than sending another huge attachment, here's another copy, including
> all the XML and some images from the IBM PPC64 machine in a new "portability"
> subsection:
>
>
Brad Benton, le Tue 29 Jun 2010 17:13:05 -0500, a écrit :
> Sure...the tarball and output files are attached.
Ok, so the physical index is explicitly -1, Linux itself doesn't know
it.
Samuel
Hello,
Jorge Gonzalez Dominguez, le Tue 29 Jun 2010 08:30:58 +0200, a écrit :
> Apologise if you receive several copies of this mail but I think the mail that
> I sent yesterday was rejected.
I actually had bounced it to the list
> On the one hand, about the OS support, [...]
> Thank you for
Christopher Samuel, le Wed 21 Jul 2010 14:48:10 +1000, a écrit :
> CC libhwloc_ports_la-topology-freebsd.lo
> topology-freebsd.c: In function ?hwloc_freebsd_set_thread_cpubind?:
> topology-freebsd.c:123: warning: passing argument 3 of
> ?pthread_setaffinity_np? from incompatible pointer type
Christopher Samuel, le Wed 21 Jul 2010 14:29:21 +1000, a écrit :
> A simple ./configure && make distcheck fails on a SuSE
> SLES 9 PPC64 box I have access to:
>
> make[1]: Entering directory `/tmp/chris/hwloc-1.0.2rc2'
> ERROR: Did not build both of the doxygen docs and README.
> ERROR: This
Jeff Squyres, le Tue 20 Jul 2010 15:22:08 -0400, a écrit :
> I think we're waiting for Samuel to get back from vacation to test on all the
> other esoteric OS's / platforms.
I have uploaded the windows build on
http://dept-info.labri.fr/~thibault/tmp/hwloc-win32-build-1.0.2rc2.zip
Still working
Bernd Kallies, le Wed 28 Jul 2010 18:09:28 +0200, a écrit :
> > > topology is understandeable. I'm wondering about "Group4", which
> > > contains the three "Group3" objects. lstopo should print "1534GB"
> > > instead of "1022GB". There is only one "Group4" object, and there are no
> > > other
Brice Goglin, le Thu 29 Jul 2010 13:01:10 +0200, a écrit :
> > To my opinion, the job hwloc does in forming "groups" is basically OK.
> > Also the group content makes sense.
>
> We're lucky that it somehow matches the physical ordering,
> but it is really meaningless given the distance matrix.
Bernd Kallies, le Fri 06 Aug 2010 18:13:06 +0200, a écrit :
> > https://svn.open-mpi.org/trac/hwloc/changeset/2360
> >
> > libibverbs is only used during make check when it's available.
>
> There is a problem with this philosophy. We provide hwloc on our
> machines in a network filesystem at a
Hello,
Changing the title for more attention by programmers :)
What people prefer to give as parameter for the membind interface? A
set of nodes (from a combination of obj->nodeset, or built by hand using
os_index of NODE objects), or a set of cpus (from obj->cpuset)?
OS interfaces take a set
Hello,
Terry Dontje, le Fri 06 Aug 2010 13:11:30 -0400, a écrit :
> Is anyone looking at replacing the Solaris processor_bind calls with
> lgrp_affinity_set calls in hwloc?
I eventually added using lgrp_affinity_set(). Not as a replacement for
processor_bind, as AIUI, lgrp_affinity_set()
Jeff Squyres, le Thu 26 Aug 2010 16:36:41 -0400, a écrit :
> Here's two images, both from the same machine, both generated via hwloc 1.0.2.
>
> Note that the PDF image is missing some characters here and there. E.g.,
> "NUMANode" on the PNG shows up as "NU ANode" on the PDF. "24MB" on the PNG
Alexey Kardashevskiy, le Thu 16 Sep 2010 15:57:47 +1000, a écrit :
> >Is the device tree linux-specific ? If so, it can stay in linux file as
> >long as it's not 30k lines :) We already have both sysfs and
> >/proc/cpuinfo code there anyway.
>
> It is powerpc-specific. It is mapped from the
Alexey Kardashevskiy, le Thu 16 Sep 2010 15:57:47 +1000, a écrit :
> >>- where do I put IBM-specific code?
> >>
> >Is the device tree linux-specific ? If so, it can stay in linux file as
> >long as it's not 30k lines :) We already have both sysfs and
> >/proc/cpuinfo code there anyway.
>
>
Samuel Thibault, le Thu 16 Sep 2010 16:57:01 +0200, a écrit :
> I'm just asking to rework the function interfaces a little bit to
> have things already cleanly separated for anybody who would feel like
> adding another OS support or parsing .dts files some day, I believe
> that shou
Pavan Balaji, le Sun 19 Sep 2010 14:16:26 -0500, a écrit :
> Thanks Samuel. This patch seems to work. There are still some warnings
> with respect to the redefinition of CPU_SET, etc.
Sure, we can't fix pgcc :)
> but it doesn't seem to be causing any runtime errors.
Good!
Samuel
Closer look on the patch:
Alexey Kardashevskiy, le Fri 17 Sep 2010 20:01:46 +1000, a écrit :
> Index: src/topology-linux.c
> ===
> --- src/topology-linux.c (revision 2443)
> +++ src/topology-linux.c (working copy)
> @@
Alexey Kardashevskiy, le Thu 16 Sep 2010 14:10:08 +1000, a écrit :
> 1. What should I change in my patch to have it committed into the svn?
> Specifically:
> - where do I put IBM-specific code?
I think it's good enough as it is now, since it's just a particular case
of the generic devtree
Alexey Kardashevskiy, le Fri 17 Sep 2010 20:01:46 +1000, a écrit :
> Regarding topology walking - there is actually nothing device-tree
> special in reading strings and numbers from a device-tree, it is just
> common functions which (I think) should be placed in utils/misc.c. I
> named
Just a last question: is it ok to include the /proc and /sys trees you
have posted in the hwloc testcases?
Samuel
Alexey Kardashevskiy, le Wed 22 Sep 2010 02:34:12 +0200, a écrit :
> What values should I use for property which is not present? cache_size =
> -1 and cache_line_size = -1 or what?
0, as other backends do.
Samuel
Brice Goglin, le Wed 22 Sep 2010 10:38:38 +0200, a écrit :
> * Some OS bind the process too when you bind memory.
Not for all kinds of memory bindings. For now, nothing that has been
commited does that, it's only the remaining TODOs. The bindings in
question are policy binding, i.e. not binding
Jeff Squyres, le Wed 22 Sep 2010 13:37:12 +0200, a écrit :
> I think we should support memory binding, even if it does weird things --
> i.e., dropping membinding support on a given OS shouldn't be an option.
That's why I'd tend to keep set_cpubind and set_membind, warning that
one may have
Brice Goglin, le Fri 24 Sep 2010 13:31:06 +0200, a écrit :
> By the way, what's the proper way to do the latter?
> #pragma weak hwloc_cpuset_foo = hwloc_bitmap_foo ?
> use __hwloc_attribute_alias instead ?
There is no proper way unfortunately: the Mach-O format used by MacOS
does not support such
Hello,
Jirka Hladky, le Wed 27 Oct 2010 14:53:01 +0200, a écrit :
> I have attached a tar file with full information.
Could you also post the result of test/linux/gather-topology.sh ?
Samuel
Brice Goglin, le Thu 28 Oct 2010 10:14:31 +0200, a écrit :
> This raises again a question that got no answer in previous emails.
> Having NULL nodeset pointers in obj->*nodeset when the machine isn't
> NUMA is annoying in many places. I think I will change to a full
> nodeset instead. It will
Jirka Hladky, le Thu 04 Nov 2010 16:59:35 +0100, a écrit :
> 3) Whenever I run lstopo using X output and I close lstopo window I will get
>
> $lstopo
> XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
> after 121 requests (121 known processed) with 0 events
Jeff Squyres, le Thu 04 Nov 2010 16:03:29 +0100, a écrit :
> I notice that the v1.1 doxygen-generated HTML has a new header style:
>
> http://www.open-mpi.org/projects/hwloc/doc/v1.1rc1/
> vs. http://www.open-mpi.org/projects/hwloc/doc/v1.0.2/
>
> Did *we* change that style, or am I using a
Jeff Squyres, le Fri 05 Nov 2010 16:29:22 +0100, a écrit :
> There are a few pending bug fixes on the 1.0.x branch. Should we do a 1.0.3
> release, just to close out the 1.0.x series?
There are a few API breaks between 1.0 and 1.1, so I guess 1.0.3 should
be released.
Samuel
Jeff Squyres, le Fri 05 Nov 2010 17:55:41 +0100, a écrit :
> If DIST_SUBDIRS is set, it trumps SUBDIRS during "make dist".
Apfff. automake is still full of surprises after having worked with it
for a few years.
Samuel
Jeff Squyres, le Mon 08 Nov 2010 15:18:01 +0100, a écrit :
> Here's a Trac colorized diff between the 1.0 branch from r2349 and the
> current HEAD:
>
> https://svn.open-mpi.org/trac/hwloc/changeset?old_path=/branches/v1.0=2349_path=/branches/v1.0=HEAD):
>
> The only interface change I see is
Jeff Squyres, le Mon 08 Nov 2010 15:38:31 +0100, a écrit :
> The last one is what I'm not sure about, but what I'm inferring from Samuel's
> statement about "API breaks".
Actually you can have an API break without an ABI break. Here, old
applications should work fine. They'll just not be able
Brice Goglin, le Mon 08 Nov 2010 16:57:44 +0100, a écrit :
> Le 08/11/2010 15:38, Jeff Squyres a écrit :
> > Short version:
> > --
> >
> > I have not looked closely -- I *think* APIs have been added and changed
> > since v1.0. As such, I *think* the libtool .so version number for 1.1
Jirka Hladky, le Thu 11 Nov 2010 13:36:46 +0100, a écrit :
> > hwloc_get_membind failed (errno 38 Function not implemented)
>
> Yes, you are right!
> --get --pid
> works on Linux.
>
> --get --membind --pid
> will give "Function not implemented"
>
> $ /tmp/hwloc-1.1rc2/utils/hwloc-bind --get
Jirka Hladky, le Thu 11 Nov 2010 14:50:46 +0100, a écrit :
> "On this system function XYZ is not supported by GLIBC/KERNEL)"
>
> I'm missing the information:
>
> -which function is not implemented
Well, you have it: hwloc_proc_getmembind()
How it'd be called by the OS in the future is unknown
Jirka Hladky, le Thu 11 Nov 2010 20:03:20 +0100, a écrit :
> On Thursday, November 11, 2010 07:19:41 pm Samuel Thibault wrote:
> > Jirka Hladky, le Thu 11 Nov 2010 14:50:46 +0100, a écrit :
> > > "On this system function XYZ is not supported by GLIBC/KERNEL)&qu
Samuel Thibault, le Tue 16 Nov 2010 22:18:54 +0100, a écrit :
> Also note that currently the hwloc_distribute() function doesn't take
> e.g. the number of PUs into account when splitting elements over the
> hierarchy. It was more a demonstration example than something to be used
> a
Brice Goglin, le Tue 16 Nov 2010 22:31:38 +0100, a écrit :
> Le 16/11/2010 15:18, Samuel Thibault a écrit :
> > Same here, distributing 4 elements between the PUs, thus selecting the
> > first 4 PUs.
> >
> > I'd say that --among should indeed be the horizontal
Hello,
Christopher Samuel, le Thu 18 Nov 2010 23:47:20 +0100, a écrit :
> Does the information occur to the right of the socket with
> the closest distance to the devices ?
If your case, hwloc was apparently unable to decide whether the devices
where "inside" one or the other NUMA node. Could
Hello,
Jirka Hladky, le Thu 18 Nov 2010 15:14:07 +0100, a écrit :
> My goal is to distribute one job per Socket with command
> hwloc-distrib --single 8
Could you try again with the current v1.1 subversion branch? I have
implemented asymmetry support.
Samuel
I agree on 1.0.3.
Brice Goglin, le Mon 22 Nov 2010 14:26:36 +0100, a écrit :
> It looks like Chris' latest problem (hwloc-bind test failing in a free)
> is not fixed yet. But we already have several important fixes, so maybe
> we can do rc3 anyway?
Good for me with the r2813 fix.
Samuel
Samuel Thibault, le Mon 22 Nov 2010 17:33:15 +0100, a écrit :
> > -- using "p" is a good way to indicate "physical". But IIRC, we didn't
> > like "l" (for "logical") because it looks too much like 1 (one).
> >
> > I think
Jirka Hladky, le Mon 22 Nov 2010 18:54:24 +0100, a écrit :
> However, I was wondering if there is some way to get the old way, i.e to
> distribute the jobs among NUMA nodes. I DO NOT use this mode but I don't want
> anybody else to be harmed.
Actually I was wondering whether it's useful at all,
Brice Goglin, le Wed 24 Nov 2010 10:15:07 +0100, a écrit :
> We should uniformize how the graphic/drawing and text outputs are called
> in the manpage/usage/doc/README, it may be a bit misleading now. But I
> am not sure which terms are best between graphic and drawing, and
> between console and
Jeff Squyres, le Tue 30 Nov 2010 14:45:13 +0100, a écrit :
> How's this, instead? I made a few minor changes:
>
> - prefixed each line of the legend (the "physical IDs" line was confusing to
> me without a prefix)
> - fixed logic for terminating timestamp string
> - moved all the legend logic
Jeff Squyres, le Tue 30 Nov 2010 17:29:15 +0100, a écrit :
> Would anyone object if I take a whack at making some SWIG bindings for hwloc?
I'd say it's welcome, as it'd easily bring bindings for other languages
as well. I'm unsure how our pointers in the hwloc_obj_t structure will
nicely map,
Guy Streeter, le Tue 30 Nov 2010 17:48:56 +0100, a écrit :
> On 11/30/2010 10:07 AM, Jeff Squyres wrote:
> >Would anyone object if I take a whack at making some SWIG bindings for
> >hwloc? I'm thinking specifically for perl (because that's my scripting
> >language of choice), but I could
bgog...@osl.iu.edu, le Tue 30 Nov 2010 18:22:29 +0100, a écrit :
> 1) NO_PCI shows nothing
>
> And I wonder if we should make (1) the default for "backward compatibility".
Possibly, yes.
(but probably not in lstopo)
Samuel
Jiri Hladky, le Fri 03 Dec 2010 11:32:01 +0100, a écrit :
> I would recommend to replace ctime with strftime function. Please note that
> ctime ignores LC_TIME. strftime on the other hand is using LC_TIME
I was wondering. strftime is supported by less operating systems. But
we can detect that,
Jiri Hladky, le Sat 04 Dec 2010 23:16:36 +0100, a écrit :
> it's a valid objection. I use only linux with pretty recent version of kernel
> and C libraries so I didn't know that strftime has portability issues.
Well, I meant that strftime has appeared "only" in susv release 3, i.e.
something like
101 - 200 of 431 matches
Mail list logo
