Le 17/02/2011 23:15, Jeff Squyres a écrit :
> I took a whack at this on OS X and Linux. I took the approach of only
> removing C99 from src/* -- this is the only part of the code base that
> embedding projects will care about. Specifically: utils and tests are still
> C99-full.
>
Here's
Le 21/02/2011 23:20, Jeff Squyres a écrit :
> In keeping with our history of confusing version numbers... ;-)
>
> Should we release 1.1.2 with the HEAD of v1.1 (there's a few pending bug
> fixes there) and call the 1.1.x series "done"?
>
> Then work ahead with releasing 1.2 with all the new stuff
Note that we may also get the same warning if the user gives a distance
matrix that conflicts with what the OS says. I don't know if we could
detect this conflict in advance to avoid the warning.
Brice
Le 23/02/2011 00:20, Jeff Squyres a écrit :
> On Feb 22, 2011, at 6:02 PM, Samuel Thibault
Le 28/02/2011 17:51, Jeff Squyres a écrit :
> Someone just made a fairly disturbing statement to me in an Open MPI bug
> ticket: if you bind some memory to a particular NUMA node, and that memory
> later gets paged out, then it loses its memory binding information -- meaning
> that it can
Le 28/02/2011 21:18, Jeff Squyres a écrit :
> On Feb 28, 2011, at 2:02 PM, Samuel Thibault wrote:
>
>
>>> That would seem to imply that I should always hwloc_set_area_membind() if I
>>> want it to persist beyond any potential future swapping.
>>>
>> I guess that could be right, but it
Le 28/02/2011 21:35, Jeff Squyres a écrit :
> On Feb 28, 2011, at 3:31 PM, Brice Goglin wrote:
>
>
>>>>> That would seem to imply that I should always hwloc_set_area_membind() if
>>>>> I want it to persist beyond any potential future swapping.
&g
Le 28/02/2011 22:04, Jeff Squyres a écrit :
> That being said, someone cited on this list a long time ago that running the
> hwloc detection on very large machines (e.g., SGI machines with 1000+ cores)
> takes on the order of seconds (because it traverses /sys, etc.). So if you
> want your
Le 28/02/2011 21:47, David Singleton a écrit :
> I dont think you can avoid the problem. Unless it has changed very
> recently, Linux swapin_readahead is the main culprit in messing with
> NUMA locality on that platform. Faulting a single page causes 8 or 16
> or whatever contiguous pages to be
Le 28/02/2011 22:30, Jeff Squyres a écrit :
> This is really a pretty terrible statement we (the Linux community) are
> making: it's all about manycore these days, and a direct consequence of that
> is that it's all about NUMA. So you should bind your memory.
>
> But that may not be enough.
Le 01/03/2011 10:46, Bernd Kallies a écrit :
> To calculate topology-based pinning schemes and do process pinning (like
> done e.g. by OpenMPI or MVAPICH2) this is too long, when every process
> (MPI task) or thread loads the topology in parallel. But exporting an
> XML topology and using this for
I just tried a PGI compiler 11.1 and couldn't compile hwloc trunk, v1.1
or even v1.0. All of them fail in the libxml headers. It looks like it
doesn't like prototypes with a variable number of arguments:
libtool: compile: /opt/cluster/compiler/pgi/linux86-64/latest/bin/pgcc
-DHAVE_CONFIG_H -I.
Le 01/03/2011 15:13, Jeff Squyres a écrit :
> Do you have a support contract with PGI, perchance?
>
I think so.
At least the link failure looks like a pgcc 11 regression. I'll check
with 11.2 and see if I can make them fix all this.
Brice
Le 01/03/2011 14:00, Brice Goglin a écrit :
> I just tried a PGI compiler 11.1 and couldn't compile hwloc trunk, v1.1
> or even v1.0. All of them fail in the libxml headers.
This is a problem with libxml2 2.7.1 (SLES11). Rebuilding a libxml2
2.7.8 fixes the problem.
> If I disable XML,
This goes with the C99 removal. It seems to fix debug-enabled build with
both gcc and pgi. But I am not familiar with valists, so somebody please
double-check.
Brice
Le 07/03/2011 11:30, bgog...@osl.iu.edu a écrit :
> Author: bgoglin
> Date: 2011-03-07 05:30:54 EST (Mon, 07 Mar 2011)
> New
Le 01/03/2011 11:00, Brice Goglin a écrit :
> Also, in 1.2, we'll have a hwloc_topology_restrict() function which will
> let you load the whole machine topology and then restrict it to whatever
> part of it (a part is defined by a hwloc_cpuset_t).
The restrict may be ready for merging in
Le 08/03/2011 10:36, Nathalie Furmento a écrit :
> On 08/03/2011 10:31, Nathalie Furmento wrote:
>> Dear hwloc-team,
>>
>> I need to compile some CUDA applications on windows, these
>> applications include (indirectly) hwloc.h.
>>
>> The nvcc compiler which uses windows visual studio complains it
Le 07/03/2011 17:56, Brice Goglin a écrit :
> Le 01/03/2011 11:00, Brice Goglin a écrit :
>
>> Also, in 1.2, we'll have a hwloc_topology_restrict() function which will
>> let you load the whole machine topology and then restrict it to whatever
>> part
Le 14/03/2011 11:19, Samuel Thibault a écrit :
> I was wondering about merging the I/O branch:
> - people have not expressed what they want so much,
> - but people will probably not until it's exposed more,
> - it's really a useful thing, and works fine in our tests,
> - I'd like to see it out :)
Le 14/03/2011 05:19, Samuel Thibault a écrit :
> I was wondering about merging the I/O branch:
> - people have not expressed what they want so much,
> - but people will probably not until it's exposed more,
> - it's really a useful thing, and works fine in our tests,
> - I'd like to see it out :)
We talk with Jeff today and came to following proposal:
We're doing to 1.1.2 now (let's flush out many small fixes that are
pending since early February).
I am not confident enough to release the PCI stuff now because it didn't
get much real testing (it still misses a bit of work in the tools
Le 31/03/2011 18:06, Jeff Squyres a écrit :
>
> Good. Although I think we should plan to make this the default in some
> future version (i.e., say that in the docs).
>
I agree with Samuel on this. Keep things people for basic users. Without
I/O devices, the topology is usually very simple,
Le 01/04/2011 21:55, Guy Streeter a écrit :
> The man page and the online documentation for
> hwloc_topology_set_synthetic() both say that it takes a
> comma-separated list as input. It appears to take a space-separated
> list instead.
> Also, the documentation does not indicate what the return
by the end of the week too.
Brice
Le 30/03/2011 22:13, Brice Goglin a écrit :
> We talk with Jeff today and came to following proposal:
>
> We're doing to 1.1.2 now (let's flush out many small fixes that are
> pending since early February).
>
> I am not confident enough to release
Le 31/03/2011 18:06, Jeff Squyres a écrit :
> On Mar 28, 2011, at 5:26 PM, Brice Goglin wrote:
>
>> libpci is needed to make this work. And only Linux gives you OS devices
>> for now (we use sysfs to translate between pci devs and os devs).
>>
> Is libpci
Hello,
What I call "GPU cores" is likely not shown by the operating systems as
"normal" cores. So hwloc would likely not show anything about them. The
new hwloc trunk has support for showing GPU devices (as long as they are
PCI devices), but we won't have any details about the cores inside these
Le 07/04/2011 03:03, MPI Team a écrit :
> /bin/sh: line 1: 20599 Segmentation fault ${dir}$tst
> FAIL: hwloc_iodevs
>
I don't know about this one, I can't reproduce it anywhere.
> /bin/sh: line 1: 20646 Segmentation fault ${dir}$tst
> FAIL: xmlbuffer
>
This one should may be
Le 07/04/2011 14:36, Jeff Squyres a écrit :
> Do we not care about rhel4 any more?
>
> I can ask IU what the possibility is of getting a RHEL5 or RHEL6 build
> machine. I don't know if it's a low or high probability.
>
I don't want to care about RHEL4 unless I have access to such machine :)
http://www.open-mpi.org/software/hwloc/v1.2/
A couple minor fixes since 1.2rc1. If nothing goes bad, we'll do the final 1.2
by the end of the week.
Brice
I am looking for a good way to specify PCI and OS devices on the
command-line (for hwloc-calc and hwloc-bind).
The trunk currently supports:
* os:foobar with for OS device named foobar (eth0, mlx4_0, ...)
* pci::00:00.0 or pci:00:00.0 for a given PCI device
* pci:::c for the c-th PCI
Le 12/04/2011 15:14, Jeff Squyres a écrit :
> On Apr 12, 2011, at 8:10 AM, Brice Goglin wrote:
>
>> I am looking for a good way to specify PCI and OS devices on the
>> command-line (for hwloc-calc and hwloc-bind).
>>
>> The trunk currently supports:
>>
Added!
thanks!
Brice
Le 12/04/2011 22:12, Rayson Ho a écrit :
> Can someone please add "Open Grid Scheduler" to the list of "...
> software already benefit from hwloc or are being ported to it" in the
> hwloc project homepage??
>
> Our homepage is:
> http://gridscheduler.sourceforge.net
>
>
De: "Jeff Squyres" <jsquy...@cisco.com>
> À: "Hardware locality development list" <hwloc-de...@open-mpi.org>
> Envoyé: Mercredi 13 Avril 2011 22:47:45
> Objet: Re: [hwloc-devel] hwloc support added in Grid Engine / Grid Scheduler
> On Apr 13, 2011, at 1:32 P
I spent some time cleaning up and documenting all this. There are likely
still some things to fix/improve, but we need some user feedback at some
point. Should start a long release-candidate cycle by doing a 1.3rc1
with the current trunk and fix many remaining things in the next RCs?
The worst
Le 13/06/2011 11:11, Christopher Samuel a écrit :
> On 12/06/11 15:45, Christopher Samuel wrote:
>
> > I *suspect* it's being pulled in by libpci - here:
>
> > $ nm /usr/lib/libpci.a | grep res_query
> > U __res_query
Hello Chris,
libpci needs -lz in some cases, maybe it needs more.
Le 13/06/2011 14:45, Jeff Squyres a écrit :
> Ah, that might explain it, then.
>
> I guess this means we need to add a few configure tests to figure out
the dependencies of libpci (if any). Yuck.
>
> Do we have any idea what function in libpci is calling the resolver
functionality?
If you pass
Le 13/06/2011 22:38, Samuel Thibault a écrit :
> Hello,
>
> Christopher Samuel, le Sun 12 Jun 2011 07:45:48 +0200, a écrit :
>>> I fail to see how that symbol can ever get into
>>> libhwloc.so, as we don't do any network thing at all...
>> I *suspect* it's being pulled in by libpci - here:
>>
>> $
Le 17/06/2011 08:40, Christopher Samuel a écrit :
> On 17/06/11 05:32, Jeff Squyres wrote:
>
> > Ok, good. I'll see if I can code this up.
>
> > ...done. Try a nightly trunk tarball >=r3516
> > (new nightly should be made in about 6 hours).
>
> Hmm, now it looks like it doesn't correctly enable
Advice from colleagues: This is becoming too ugly, this is libpci's
fault, just always add -lz -lresolv and let the linker drop them later
if they're useless :)
Brice
Le 17/06/2011 10:04, Christopher Samuel a écrit :
> On 17/06/11 17:14, Brice Goglin wrote:
>
> > Is there anyway to t
Le 03/07/2011 23:55, Jiri Hladky a écrit :
> Hi all,
>
> I have come across tests/hwloc_distances test and I believe that it
> would be great to convert this into the utility
> "hwloc-report-instances" published under utils/ directory. Please let
> me know what you think about it.
>
> It would
... yes
checking for pci_lookup_name in -lpci with -lresolv... yes
RHEL5.3:
checking for pci/pci.h... yes
checking for pci_init in -lpci... yes
checking for pci_lookup_name in -lpci... yes
Christopher, it should work starting with trunk r3535.
Brice
Le 30/06/2011 07:50, Brice Goglin a écrit
Le 05/07/2011 22:04, Jiri Hladky a écrit :
> Well, this is interesting. numactl --hardware shows the number of
> hops, regarding to the information from that private BZ.
I think this is wrong. numactl takes everything from sysfs as far as I
can tell. On x86, sysfs distances are ACPI SLIT
Le 03/08/2011 12:46, Samuel Thibault a écrit :
> Also, it seems that on your system the processing units are gathered 4
> by 4 (exposed as a "group" in hwloc). Do you happen to know what this
> physically correspond to?
Power6 is dual-core dual-thread and we don't have sockets in this
output, so
Hello,
While playing with static hwloc libraries and binaries [1], I had to
manually add -lpthread to LIBS to get the fully-static binaries to link
properly. We use some pthread functions, so is there a good reason not
to put -lpthread in LIBS? (and HWLOC_REQUIRES?)
Brice
[1]
Le 04/08/2011 17:03, Samuel Thibault a écrit :
> Brice Goglin, le Thu 04 Aug 2011 16:58:19 +0200, a écrit :
>> While playing with static hwloc libraries and binaries [1], I had to
>> manually add -lpthread to LIBS to get the fully-static binaries to link
>> properly.
&
Le 04/08/2011 17:48, Samuel Thibault a écrit :
> Brice Goglin, le Thu 04 Aug 2011 17:47:17 +0200, a écrit :
>> /home/bgoglin/SOFT/hwloc/branch-1.2/build/src/.libs/libhwloc.a(topology-linux.o):
>> In function `hwloc_linux_set_thread_cpubind':
>> topology-linux.c:(.text+0x1070)
Le 04/08/2011 18:14, Samuel Thibault a écrit :
> Brice Goglin, le Thu 04 Aug 2011 18:06:24 +0200, a écrit :
>> Le 04/08/2011 17:48, Samuel Thibault a écrit :
>>> Brice Goglin, le Thu 04 Aug 2011 17:47:17 +0200, a écrit :
>>>> /home/bgoglin/SOFT/hwloc/branch-1.2/build
Le 25/08/2011 00:19, Samuel Thibault a écrit :
> bgog...@osl.iu.edu, le Wed 24 Aug 2011 17:27:50 +0200, a écrit :
>> + HWLOC_BACKEND_CUSTOM,
> Actually, maybe rather than "custom", use "empty"?
Could be better yes.
I am also thinking of renaming the corresponding insert functions to
have a
Some notes about this commit:
The interface already supports having multiple distance matrices for the
same type. For instance, if you have distances between NUMA nodes of a
single machine, once you assemble multiple machines, you get multiple
distance submatrices. However, loading from XML is
Le 03/07/2011 23:55, Jiri Hladky a écrit :
> Hi all,
>
> I have come across tests/hwloc_distances test and I believe that it
> would be great to convert this into the utility
> "hwloc-report-instances" published under utils/ directory. Please let
> me know what you think about it.
>
> It would
Did you actually find many machines/distribs that don't have libxml2
installed by default? There are literaly hundreds of packages that
depend on libxml2 (at least in Debian) so I am not sure depending on it
is really a problem.
Also are there really some string space problems? Even when talking
Le 01/09/2011 18:01, Jeff Squyres a écrit :
> I could *probably* write this, but I'm guessing you guys could write it much
> faster than I could...
Support for the most useful attributes would be done within a couple
hours. The annoying thing is to support all attributes, distances, ...
Also
JSON looks a bit more verbose than YAML, but JSON also looked better for
our hierarchical information, so I gave JSON a try. I just pushed the
result to the new json branch.
Notes:
* You can only load/save from/to a memory buffer (set_jsonbufffer and
export_jsonbuffer), but lstopo needed to
(side note from the current discussion about XML/JSON/...)
The doc of hwloc_topology_export_xmlbuffer() says that the returned
buffer should be freed with xmlFree(). xmlFree() is in libxml2, but
hwloc can be built without libxml2 support. So the application can
always use
Samuel thinks we could stay with XML and reimplement our own
parsing/dumping without libxml2.
My feeling about this is:
+ We would have a single file format for import/export.
+ Saving would likely be easy (copy-paste from the current code and/or
from the JSON export)
- Parsing would require some
Le 04/09/2011 18:26, Igor Galić a écrit :
> Hi folks,
>
> first off: I would've submitted this Bug report via Trac if I could have
> done it anonymously. I *tried* to register, but the captcha was impossible
> to decipher -- And I can see! I strongly suggest you replace this with
> reCaptcha. It
v1.3rc1 has been released two weeks ago and many things are going on
right now, in all branches:
* I just finished fixing my pile of distance-related bugs (thanks to
multinode support and OMPI users). I backported the really important
ones in v1.3 and v1.2. Do we want a 1.2.2?
* I applied some
Le 06/09/2011 16:53, Jeff Squyres a écrit :
> On Sep 6, 2011, at 10:44 AM, Brice Goglin wrote:
>
>> v1.3rc1 has been released two weeks ago and many things are going on
>> right now, in all branches:
>> * I just finished fixing my pile of distance-related bugs (thanks
Hello Terry,
Indeed there's nothing like this as of today. We talked about it in the
past but it's not very easy to implement on Linux (see below) so we
forgot about it until somebody complained.
Adding infos would certainly be fine. I think it should rather be
"CPUType" and "CPUModel" since
Le 09/09/2011 13:25, TERRY DONTJE a écrit :
> On 9/8/2011 3:10 PM, Brice Goglin wrote:
>> Hello Terry,
>>
>> Indeed there's nothing like this as of today. We talked about it in
>> the past but it's not very easy to implement on Linux (see below) so
>> we forgot a
Le 09/09/2011 13:25, TERRY DONTJE a écrit :
> On 9/8/2011 3:10 PM, Brice Goglin wrote:
>> Hello Terry,
>>
>> Indeed there's nothing like this as of today. We talked about it in
>> the past but it's not very easy to implement on Linux (see below) so
>> we forgot a
Le 12/09/2011 21:01, Brice Goglin a écrit :
> Le 09/09/2011 13:25, TERRY DONTJE a écrit :
>> On 9/8/2011 3:10 PM, Brice Goglin wrote:
>>> Hello Terry,
>>>
>>> Indeed there's nothing like this as of today. We talked about it in
>>> the past but it's n
Le 13/09/2011 21:51, TERRY DONTJE a écrit :
>
>
> On 9/13/2011 9:23 AM, Brice Goglin wrote:
>> Le 12/09/2011 21:01, Brice Goglin a écrit :
>>> Le 09/09/2011 13:25, TERRY DONTJE a écrit :
>>>> On 9/8/2011 3:10 PM, Brice Goglin wrote:
>>>>> H
I pushed the new minimalistic XML import/export implementation without
libxml2 to the nolibxml branch. If libxml2 is available, it's still used
by default. --disable-libxml2 or some env variables can be used for
force the minimalistic implementation if needed. The minimalistic implem
is only
Le 20/09/2011 14:44, Jeff Squyres a écrit :
> 1. Is it permissible to use _PROCESS or _THREAD with
> get_proc_last_cpu_location() and get_proc_cpubind()? I'm thinking that it
> doesn't make sense to use _THREAD here, and using _PROCESS would be redundant.
That's almost true. Except that Linux
People interested in multinode topology support (or network topology),
please look at this and send your thoughts.
The "custom" branch is in good shape, I'd like some feedback before
merging it to trunk.
Example of C interface use (assembling 3 nodes in a global topology with
3 levels of
Hello Ralph,
Indeed, adding something before the cache size might be good.
But if I was picky, I would say "size=32kB linesize=64". The word
"Cache" is already written above (in the object type), why would we
duplicate it in "Cachesize" and "Cacheline" ?
Right now, lstopo shows:
L3Cache L#3
Le 22/09/2011 22:42, Ralph Castain a écrit :
> I guess I didn't get that from your documentation. Since caches sit
> between socket and core, they appear to affect the depth of the core
> in a given socket. Thus, if there are different numbers of caches in
> the different sockets on a node, then
It works fine here.
It's basically similar to tests/embedded/ stuff (all files
in the parent EXTRA_DIST, nothing in SUBDIRS so that automake
doesn't know about it).
Adding this Makefile.in the list of files that configure has
to manage shouldn't be a problem, we already have many .in
files that
Le 23/09/2011 21:33, Jeff Squyres a écrit :
> Sorry, I was OTP when I sent that, and not fully focused.
>
> My concern is that this file must be generated via an AC_CONFIG_FILE
> somewhere, right? And therefore it must be included in the tarball, etc.
Yes, and it's included in the tarball (see
004009b8 in main () at xmlbuffer.c:31
>
> On Sep 24, 2011, at 9:45 AM, Brice Goglin wrote:
>
>> Indeed, this object contains invalid pointers.
>>
>> Can you try to run tests/xmlbuffer.c from hwloc's tree? It does
>> export+import+export+compare on the same machine. It
Le 04/10/2011 16:51, Samuel Thibault a écrit :
> This looks good. hwloc-assembler-remote should probably have a
> --lstopo-path option to specify where to find lstopo, since the host
> from which we run it may not have the same hwloc installation as the
> target nodes. I'm actually unsure whether
Anybody against releasing the final v1.3?
We only had the following changes since v1.3rc2. Nothing worth a new
tarball?
* Fix lstopo crash in verbose messages about offline/disallowed/...
processors when root has no cpuset, just don't display anything for now
* Update
Le 11/10/2011 15:04, Jeff Squyres a écrit :
> Looks like Ralph's size/linesize patch didn't make it to v1.3:
>
> Index: src/traversal.c
> ===
> --- src/traversal.c (revision 3883)
> +++ src/traversal.c (working copy)
> @@ -478,7
I just released the final v1.3 (official announce mail coming later).
I will likely merge the custom branch into trunk in the next days so
that the multinode topology support gets wider testing.
The other big thing on my TODO list for v1.4 is throughput distance
matrix. This one is a bit
Le 12/10/2011 22:56, Jeff Squyres a écrit :
> One of the OMPI devs found a problem when I upgraded the OMPI SVN trunk to
> the hwloc 1.2.2ompi version last week that I think I am just now beginning to
> understand.
>
> Brief reminder of our strategy:
>
> - on each compute node, OMPI launches a
Hello,
The v1.2 branch has known problems with distance matrices when the
topology is asymmetric (especially when Linux cpuset make some NUMA
nodes CPU-less). This is what causes wrong relative_depth here. It can
even be negative is some cases which is obviously wrong.
This should be fixed in
import.
Brice
Le 02/11/2011 14:59, Jeff Squyres a écrit :
> Should we just filter out the "distance" attribute in the XML on the v1.2ompi
> branch? We're not using it (yet) in OMPI.
>
> On Nov 2, 2011, at 9:32 AM, Brice Goglin wrote:
>
>> Hello,
>>
>
Objet : [hwloc-devel] hwloc 1.3.1 needed?
Date : jeu., nov. 3, 2011 17:03
Brice Goglin, le Thu 03 Nov 2011 16:29:52 +0100, a écrit :
> I am not sure how bad this bug was, so I don't know if it deserves a
> v1.3.1 soon.
The bug simply disables PCI support on sy
I'll backport the Sun Studio hidden visibility stuff (r3773 + below) to
v1.3 unless somebody complains. Terry had to fix it in OMPI already.
Brice
Le 22/11/2011 08:57, bgog...@osl.iu.edu a écrit :
> Author: bgoglin
> Date: 2011-11-22 02:57:54 EST (Tue, 22 Nov 2011)
> New Revision: 3961
> URL:
I don't see any call to cuInit(). Does it mean that we don't have to
wait 3s during startup as usual with CUDA?
Brice
Le 25/11/2011 08:56, sthib...@osl.iu.edu a écrit :
> Author: sthibaul
> Date: 2011-11-25 02:56:52 EST (Fri, 25 Nov 2011)
> New Revision: 3971
> URL:
Le 25/11/2011 08:56, sthib...@osl.iu.edu a écrit :
> +static hwloc_obj_t hwloc_topology_get_pcidev(hwloc_topology_t topology,
> hwloc_obj_t parent, int domain, int bus, int dev)
> +{
> + hwloc_obj_t child;
> +
> + if (parent->type == HWLOC_OBJ_PCI_DEVICE
> + && parent->attr->pcidev.domain
Le 28/11/2011 22:34, Guy Streeter a écrit :
> This question may be more about understanding NUMA (which I barely do) than
> about hwloc, but perhaps you can help anyway.
>
> I have a customer with some HP Proliant DL580 G7 servers. HP supplied them
> with a block diagram of their system, and it
Le 07/12/2011 23:12, Brice Goglin a écrit :
>> So my question is, are there plans to add a configure switch in hwloc
>> to disable libnuma??
> Hello,
> There's no plan, but that's certainly possible if multiple people keep
> facing this issue.
Here's a patch that impleme
Le 08/12/2011 15:48, Rayson Ho a écrit :
> Thanks a lot, Brice.
>
> I hacked something similar for 1.2.2 last night, but your patch is
> more complete (I didn't modify hwloc_internal.m4 to include the help
> message). I will probably wait for the next 1.2.x hwloc release, and
> then refresh Open
I want to release 1.3.1 for christmas, so I'll do a 1.3.1rc1 on monday.
There are no critical fixes in there, but several changes that are
useful, so it's better to finally flush all these (some have been
waiting almost since the 1.3.1 two months ago).
Additionally, some people want a multinode
Le 09/12/2011 12:10, jsquy...@osl.iu.edu a écrit :
> ''Really'' fix the $HWLOC_PKG_CONFIG --> $PKG_CONFIG issue. Don't
> > just rename it in HWLOC_PKG_PROG_PKG_CONFIG, but everywhere throughout
> > hwloc_pkg.m4.
Thanks, I had pretty much the same in my tree, and it seems to work fine.
> >
Le 09/12/2011 13:47, Jeff Squyres a écrit :
> 1. Will there ever be any differentiation between cache levels in
> hwloc_obj.type? I ask because in OMPI, we found that the various counting
> routines were not helpful because they only search by *type*, not by
> (obj.type,
Le 13/12/2011 12:14, Samuel Thibault a écrit :
> Do we merge the cuda branch into 1.4? I didn't do the work directly
> into the trunk because I wasn't sure of what I'd need to add to the
> interface. Eventually, the additions are
>
> - the "tight" field, which just means whether children are
Le 13/12/2011 16:45, Jeff Squyres a écrit :
> On Dec 13, 2011, at 10:40 AM, Brice Goglin wrote:
>
>> In most cases, you don't need PCI support for this, you juste manipulate
>> a cuda device, an ibv_device, a MX endpoint, ... and use one of the
>> inline helpers to get th
Le 13/12/2011 18:02, Samuel Thibault a écrit :
> Brice Goglin, le Tue 13 Dec 2011 16:41:08 +0100, a écrit :
>> Le 13/12/2011 16:22, Jeff Squyres a écrit :
>>> I can't speak for GPUs, but I think the PCI information will be useful to
>>> know what devices are clo
You should also error out if --enable-cuda is given and cuda isn't
found. We got some complains about this for XML and PCI. Just duplicate
the xml_happy stuff for cuda.
Brice
Le 13/12/2011 18:15, sthib...@osl.iu.edu a écrit :
> Author: sthibaul
> Date: 2011-12-13 12:15:09 EST (Tue, 13 Dec
Le 13/12/2011 18:13, Jeff Squyres a écrit :
> I see this in the category of: users really need to do this anyway, so
> either we're forcing every user to do it, or they're ignoring it and
> just using "available" or "online", which may not always give correct
> results. So we might as well provide
Le 13/12/2011 18:17, Samuel Thibault a écrit :
> Brice Goglin, le Tue 13 Dec 2011 14:10:17 +0100, a écrit :
>> My main problem is that it's hard to know whether this will look good in
>> two years when we'll have support for AMD APU, Intel MIC and other
>> "strange&q
Le 13/12/2011 18:47, Samuel Thibault a écrit :
> I'd say that some people might want WHOLE_SYSTEM while still needing
> the bindable cpuset.
Let's wait for those people to complain before adding a 8th
cpuset/nodeset to the object structure. If they do complain and they
really don't want to AND
Le 13/12/2011 19:30, Samuel Thibault a écrit :
> Ok, I thought you were referring to an architectural detail. Well,
> actually NUMA nodes and embedded memory should just both use a MEM
> object, instead of duplicating all kinds of objects. We won't duplicate
> such things for the MIC, will we?
My
Le 14/12/2011 09:53, Samuel Thibault a écrit :
> Paul H. Hargrove, le Wed 14 Dec 2011 09:50:23 +0100, a écrit :
>> It appears that something has passed bogus arguments to hwloc-calc.
>> Adding "set -x" in test-hwloc-calc.sh.in I can find the failure is from:
>> ./hwloc-calc --if synthetic
I am seeing many warning like these since yesterday:
In file included from /home/bgoglin/SOFT/hwloc/trunk/include/hwloc.h:49:0,
from ../../utils/lstopo.h:12,
from ../../utils/lstopo-color.c:11:
We've been debugging some problems on Redhat 8 with Paul Hargrove and
here's one problems that remains.
CC topology-linux.lo
../../src/topology-linux.c:71: conflicting types for `sched_setaffinity'
/usr/include/sched.h:69: previous declaration of `sched_setaffinity'
Le 14/12/2011 11:34, Samuel Thibault a écrit :
> Brice Goglin, le Wed 14 Dec 2011 11:21:30 +0100, a écrit :
>> His sched.h defines the very old prototype of sched_setaffinity (pid,
>> len, ulong*).
> Urgl. Is it actually "very old"? I thought it was just a transient
&
Le 14/12/2011 20:45, Paul H. Hargrove a écrit :
> I can run "lspci -vv" to get plenty of correct information and no such
> messages.
What about lspci -vvxxx ? These options makes the pci lib read 256
instead of 64 bytes of config space ?
I may need to check something in the first 64bytes before
201 - 300 of 616 matches
Mail list logo
