Le 14/12/2011 21:56, Paul H. Hargrove a écrit :
> Now that I think of it, this situation seems to imply that running the
> code in topology-libpci.c as root on a system w/ a Intel PIIX4
> controller could lock-up ones machine. Thoughts?
I can't know for sure. I would be surprised if sudo lspci
Le 14/12/2011 22:42, Paul H. Hargrove a écrit :
>
>
> On 12/14/2011 1:21 PM, Brice Goglin wrote:
>> The attached patch might work. I am not sure all this is actually
>> necessary because things have been working fine so far, apart from your
>> warnings.
>
> Yup
Le 15/12/2011 16:31, bgog...@osl.iu.edu a écrit :
> Author: bgoglin
> Date: 2011-12-15 10:31:50 EST (Thu, 15 Dec 2011)
> New Revision: 4069
> URL: https://svn.open-mpi.org/trac/hwloc/changeset/4069
>
> Log:
> Fix a long-standing obsolete PREDEFINED in the website doxygen config
There are still
Le 16/12/2011 16:03, Jeff Squyres a écrit :
> There have been a bunch of updates that have (rightfully) not been
> back-ported to the 1.2-ompi branch.
>
> Is 1.3.x stable/mature enough for me to move into OMPI?
>
> I have two targets:
>
> * Open MPI v1.5 series: we're just about to release the
Le 24/01/2012 00:25, Samuel Thibault a écrit :
> On 23/01/12 20:34, Brice Goglin wrote:
>> Please test and let us know if you find any issue.
> Can somebody try it on AIX?
Looks like v1.4rc2 had way less problems than rc1. If somebody can test
on AIX or any uncommon platform soon, I'l
Hello,
I'd like to see what hwloc reports on AMD machines with a HTX card
(hypertransport expansion card). The most widely known case would likely
be a 3-5-years old AMD cluster with Pathscale Infinipath network cards.
But I think there are also some accelerators such as clearspeed, and the
The bitmap code uses ffs*() to find the first bit set.
Brice
Le 01/02/2012 11:58, Jeff Squyres a écrit :
> Paul -- any idea what library that symbol actually lives in?
>
> FWIW, I can't find that symbol -- or anything like it -- in the hwloc code
> base. Is it being pulled in by some dependent
Thanks, this should be fixed in trunk >= r4230, I'll backport in other
branches soon. We didn't need add -lm for fabs() because gcc uses an
intrinsics, and libxml2 depends on libm, quite lucky.
Brice
Le 01/02/2012 03:48, Paul H. Hargrove a écrit :
> The problem I described below is ALSO present
Le 01/02/2012 03:49, Christopher Samuel a écrit :
> With XLC and 1.3.1 and 1.4 I get plenty of warnings (compile logs for
> both attached) whilst compiling and then 4 failures in make check
> (accompanied with segmentation faults):
>
> samuel@tambo:~/HWLOC/hwloc-1.3.1> grep -B1 FAIL: log
>
Can you run hwloc-gather-topology and send the resulting tarball and
output ?
We've seen some powerpc machines where the old kernel didn't say much
about the topology, so your 8 cores with 4 threads appeared as 32 things
without much details about their organization. I assume you can't
upgrade the
Le 01/02/2012 23:59, Christopher Samuel a écrit :
> On 02/02/12 00:20, Brice Goglin wrote:
>
> > This looks very bad. It means something screwed the already very complex
> > sched_setaffinity detection code.
> > Does XLC redefine its own sched_setaffinity functions? Can y
We could also AC_TRY_LINK a program that uses ffsfoo (the one that
actually breaks here).
If it fails, we AC_TRY_LINK a program that uses ffsfoo with the
__ffssi2() definition.
If it fails, we define NEED_FFS_FIX
And we just add the fix under #ifdef NEED_FFS_FIX in private/misc.h.
Would that work?
Le 01/02/2012 04:12, Paul H. Hargrove a écrit :
> The problem I reported below also exists in hwloc-1.4.1.
> Additionally, I can reproduce the SEGVs with xlc which Chris Samuel
> reported in
> http://www.open-mpi.org/community/lists/hwloc-devel/2012/01/2738.php
>
> -Paul
>
> On 1/31/2012 5:56
Le 02/02/2012 10:53, Brice Goglin a écrit :
> Le 01/02/2012 04:12, Paul H. Hargrove a écrit :
>> The problem I reported below also exists in hwloc-1.4.1.
>> Additionally, I can reproduce the SEGVs with xlc which Chris Samuel
>> reported in
>> http://www.open-mpi.org/
Le 08/02/2012 22:33, Paul H. Hargrove a écrit :
>
>
> On 2/8/2012 8:58 AM, Jeff Squyres wrote:
>> * Fix conversion from/to Linux libnuma when some NUMA nodes have no
>> memory.
>
> Tests on the virtual node I have access to where that problem report
> originated is still not quite right.
> There
While debugging libnuma helpers, I needed a way to emulate remote
topologies in libnuma as hwloc does so that we can do
HWLOC_FSROOT=/foo/bar tests/linux-libnuma
on any of my existing remote topologies. I modified 2.0.8-rc3 with the
attached patch so that it honors HWLOC_FSROOT when reading /sys
Hello,
"make check" doesn't report any single memory leak under valgrind
anymore in trunk... except those from external libs such as libpci and
libxml. I created the attached suppressions file to hide them when
valgrind'ing hwloc programs. Just pass --suppressions=hwloc.supp to
valgrind.
For the
Karl,
I'll release hwloc 1.4.1rc2 with Samuel's changes on Monday. If you need
the fix earlier, you can apply
https://svn.open-mpi.org/trac/hwloc/changeset/4345
or checkout svn branch v1.4
or use the nightly build that will be updated tomorrow early morning at
In case somebody tries to build from SVN with the new bleeding-edge
doxygen 1.8.0, you will likely get a failure in the latex compilation.
It's likely a doxygen bug, but it may also be hwloc.doxy containing some
non-doxygen-compatible syntax. We'll see.
Hello,
I think I will merge the icache branch by the end of the week if nobody
complains.
This new branch adds a type attribute to cache objects, which can be
DATA, INSTRUCTION or UNIFIED. On Linux sysfs, everything is detected
properly. I am working on the devicetree code. Other OSes currently
name: | hwloc-1.5a1-1
> Short description: | Native Nix build on x86_64-linux
> Maintainer(s): | Samuel Thibault <samuel.thiba...@inria.fr>, Brice
> Goglin <brice.gog...@labri.fr>
> System:| x86_64-linux
> Derivation store path: |
>
We'll have to check the compatiblity of this thing with the hwloc
membind API if/when it gets merged in the Linux kernel.
Lee Schermerhorn's Migrate-on-Fault is supposed to be
hwloc_membind_nexttouch, that would be a very good news.
Brice
Message original
Sujet: [RFC][PATCH
These come from the icache branch merge. It was merged on 2012/03/16,
and nightly builds and our local testing look happy since then. Do you
need a fresh checkout and/or make maintainer-clean?
Brice
Le 20/03/2012 12:51, Jeffrey Squyres a écrit :
> Sorry -- I should have done a "make -k" first:
Le 20/03/2012 19:02, Jeffrey Squyres a écrit :
> On Mar 20, 2012, at 12:02 PM, Brice Goglin wrote:
>
>> Actually, what we don't know is how to map that to port 1/2 (we have
>> ib0/ib1 mac addresses, those are = GUID+1/2 on my machine)
>
> Yes, that is more correctly st
Le 20/03/2012 20:30, Jeffrey Squyres a écrit :
> On Mar 20, 2012, at 3:29 PM, Brice Goglin wrote:
>
>> By the way, do you want Port numbers to start at 0 or 1?
>
> IIRC, IB (and probably RoCE) port numbers start with 1. Shrug.
>
> So let's report whatever they report.
&
Le 20/03/2012 21:48, Jeffrey Squyres a écrit :
> On Mar 20, 2012, at 3:45 PM, Brice Goglin wrote:
>
>> That looks good to me, as long as starting port numbers to 1 for
>> non-IB/OFED is OK.
>
> Hmm. Not sure about that. I always thought it was strange that IB device
Le 20/03/2012 21:48, Jeffrey Squyres a écrit :
> On Mar 20, 2012, at 3:45 PM, Brice Goglin wrote:
>
>> That looks good to me, as long as starting port numbers to 1 for
>> non-IB/OFED is OK.
>
> Hmm. Not sure about that. I always thought it was strange that IB device
Le 20/03/2012 22:12, Jeffrey Squyres a écrit :
> On Mar 20, 2012, at 5:07 PM, Brice Goglin wrote:
>
>> New patch attached, it doesn't add port numbers for non-IB devices.
>
> Does the new patch add port numbers at all if /device/infiniband doesn't
> exist?
No. For each
I don't see anything bad in your outputs.
So there's something strange going on when MPI is added. Which MPI are
using? Is this a derivative of MPICH that embeds hwloc? (MPICH >= 1.2.1
if I remember correctly)
Brice
Le 21/03/2012 15:08, Daniel Ibanez a écrit :
> Attached is the stderr and
Le 22/03/2012 23:07, Daniel Ibanez a écrit :
>
> I suspected this might be the reason, so I called "nm"
> with the static versions of the libraries their compiler wrappers
> link against and I could not find the term "hwloc" in the output.
> Is this a valid test?
If your hwloc is still compiled
Le 22/03/2012 23:33, Daniel Ibanez a écrit :
> I've run this test before (didnt keep the results but can run it again).
> I got debug output and compared it with the output from a hwloc test
> executable
> and I noticed that my program did not show any PU objects were discovered.
> In my program
Le 24/03/2012 23:04, Daniel Ibanez a écrit :
> The fundamental difference is in
>
> src/topology-linux.c:3251
>
> when this if statement is true, hwloc_setup_pu_level
> finds the PU objects.
> When it is false, it fails with empty topology.
>
> I checked HWLOC_LINUX_USE_CPUINFO,
> and it is not
Le 26/03/2012 05:16, Christopher Samuel a écrit :
> On 25/03/12 09:04, Daniel Ibanez wrote:
>
> > Additional printfs confirm that with MPI in the code,
> > hwloc_accessat succeeds on the various /sys/ directories, but the
> > overall procedure for getting PUs from these fails. Without MPI,
> >
Well, I tend to not backport new stuff to stable branches before I am
sure they work fine on trunk :) We haven't even tested this on many
Linux kernels and OFED hardware yet.
The risk is very low here. So if you need it, I can certainly backport it.
Brice
Le 27/03/2012 22:27, Jeffrey Squyres
MPI
> trunk, and hoping that this feature will be in it.
>
> So there's no huge rush -- I was just making sure this didn't get dropped.
>
>
> On Mar 27, 2012, at 4:31 PM, Brice Goglin wrote:
>
>> Well, I tend to not backport new stuff to stable branches before I am
>>
Le 31/03/2012 04:06, Pavan Balaji a écrit :
> Hi all,
>
> The hwloc code seems to shadow some previously defined variables.
> These warnings show up when configured with CFLAGS=-Wshadow with gcc.
> Here's a patch to fix these warnings:
>
> https://trac.mcs.anl.gov/projects/mpich2/changeset/9656
Hello,
We recently got some complains from redhat/centos users that wanted to
install hwloc on their cluster but couldn't because it brought so many X
libraries that they don't care about.
Debian solves this by having two hwloc packages: the main hwloc one, and
hwloc-nox where cairo is
On 25/04/2012 16:55, Jeff Squyres wrote:
On Apr 25, 2012, at 10:48 AM, Samuel Thibault wrote:
FWIW: Having lstopo plugins for output would obviate the need for having two
executable names.
Well, it seems overkill to me. It makes sense to me to have both
xlstopo and lstopo.
Ick. FWIW, I
On 26/04/2012 08:11, Christopher Samuel wrote:
On 26/04/12 02:35, Brice Goglin wrote:
I think I would vote for lstopo (no X/cairo) and lstopo so
that completion helps.
Not sure if that's an option with Debian given the policy; the hwloc
package would have to have lstopo with X enabled
Le 25/04/2012 15:42, Jiri Hladky a écrit :
> I would vote to make lstopo ASCII only and introduce new GUI binary
> "lstopo-gui" in the version 1.5
I'll commit that during the weekend unless somebody comes with a better
solution.
Of course, distros are free to add symlinks as Xlstopo then :)
Le 27/04/2012 19:22, Samuel Thibault a écrit :
> Brice Goglin, le Fri 27 Apr 2012 19:09:47 +0200, a écrit :
>> Le 25/04/2012 15:42, Jiri Hladky a écrit :
>>> I would vote to make lstopo ASCII only and introduce new GUI binary
>>> "lstopo-gui" in the v
Bouncing this to -devel for archive.
Brice
Message original
Sujet: RE: hwloc/windows
Date : Sun, 29 Apr 2012 11:59:29 -0500
De :Hartmut Kaiser <hartmut.kai...@gmail.com>
Répondre à :<hartmut.kai...@gmail.com>
Pour : 'Brice Goglin' <brice.gog...@inr
Thanks _very_ much Hartmut for all the testing.
The 32bits output looks broken as expected. Anything containing a bit >=
32 is invalid. That's why no core >= 32 appears, and no
socket/numanode/cache containing a core >= 32 appears.
The warning means that windows gave us a bitmask that conflicts
Le 01/05/2012 20:00, Jeff Squyres a écrit :
> On May 1, 2012, at 10:52 AM, Jeff Squyres wrote:
>
>> 2. Somehow, when I configure and build the hwloc trunk on my mac, it won't
>> provide any graphical output formats. But when I configure and build the
>> hwloc 1.4 branch on my mac, all the
Le 01/05/2012 19:52, Jeff Squyres a écrit :
> 1. On an admittedly pre-production Cisco sandy bridge server, I ran "lstopo
> foo.xml", which ended up putting a ctrl-A in the value of the following line:
>
>
>
> I.e., the value was quote ^A quote. This caused barfage when trying to use
>
>
> Regards Hartmut
> ---
> http://boost-spirit.com
> http://stellar.cct.lsu.edu
>
>
>
>> -Original Message-
>> From: Brice Goglin [mailto:brice.gog...@inria.fr]
>> Sent: Tuesday, May 01, 2012 7:40 AM
>> To: hartmut.kai...@gmai
The current list of NEWS for 1.4.2 is
http://svn.open-mpi.org/svn/hwloc/branches/v1.4/NEWS
Anybody sees something missing?
Brice
Le 01/05/2012 20:39, Jeff Squyres a écrit :
> On May 1, 2012, at 11:24 AM, Brice Goglin wrote:
>
>>> Should we filter characters that we know the input parser won't accept?
>> Are you using libxml2 or the basic XML support ?
> In both cases (input and output), libxml2.
FWI
I'll likely release the final 1.4.2 tomorrow without any change unless
something bad happens in the meantime.
Brice
Le 03/05/2012 14:51, Brice Goglin a écrit :
> The Hardware Locality (hwloc) team is pleased to announce the first
> release candidate for v1.4.2:
>
>http://www.
(3) is of course OK, and (2) should be OK too, so I'll apply them to
v1.4 and trunk.
(1) is for Jeff.
Brice
Le 11/05/2012 20:35, Pavan Balaji a écrit :
> Hi all,
>
> We just upgraded to hwloc-1.4.2. We'd like to push upstream some
> patches that we maintain, if you find them appropriate.
>
>
Le 24/05/2012 17:16, Jeff Squyres a écrit :
> Just for the record, I really, really dislike the fact that we've now split
> lstopo into lstopo and lstopo-gui.
>
> Especially since I keep flipping back and forth between hwloc 1.4 and the
> hwloc trunk, I continually get it wrong on the command
Le 24/05/2012 22:14, Jeff Squyres a écrit :
> On May 24, 2012, at 11:30 AM, Brice Goglin wrote:
>
>> So what you dislike isn't the split, it's the fact that lstopo doesn't
>> behave as it did earlier. You want lstopo-nogui and lstopo instead of
>> lstopo and lstopo-gui. And
Le 25/05/2012 07:23, Brice Goglin a écrit :
> Le 25/05/2012 02:38, Christopher Samuel a écrit :
>> On 25/05/12 06:14, Jeff Squyres wrote:
>>
>>> Are there other traditional suffixes that are used for this kind of
>>> thing? Or is lstopo kinda unique in this area
Le 25/05/2012 12:34, Jeff Squyres a écrit :
> Hmm. I typed "lstopo-no-graphics" above, just to be descriptive, but
> is that a horrible name? If the main goal is for binary packagers who
> assumedly have /etc/alternative-type solutions such that users will
> rarely/never type that full name, how
The current -lpicl in src/Makefile.am comes from Terry's initial Solaris
CPUModel detection patch. If Terry is ok, I am fine with your change as
well.
Brice
Le 12/06/2012 16:19, Jeff Squyres a écrit :
> I recently upgraded OMPI's SVN trunk to hwloc 1.4.2, and immediately broke
> builds on
Hello Hendryk,
I am re-adding hwloc-devel to CC since we have a non-trivial patch
attached and discussion below.
I talked to your IBM contact and he was indeed able to help, thanks. So
there are indeed two different binding interfaces on AIX. hwloc only
support rsets, that's why we don't see
Hello Terry,
Here's a patch that should help. It cleans the code and makes all arrays
dynamic. I artificially set the initial array sizes to 4 to experience
the code on our 24-way T1 machine. I will set it to 256 or so in the
final commit. Please let me know if it helps on your 1440-way machine.
In July hopefully.
Brice
TERRY DONTJE <terry.don...@oracle.com> a écrit :
How soon will 1.5 be released? I would like to get it into the OMPI trunk and
1.7.
--td
On 6/29/2012 8:19 AM, Brice Goglin wrote:
Thanks for testing.
I'll commit to trunk for sure. I don't know about 1.4 sinc
+.SH HINT
+To check what the result actually is, use
+
+hwloc-bind blabla -- lstopo --pid 0
+
+lstopo will graphically show where it is bound to by hwloc-bind.
My lstopo doesn't show anything with such a command (--pid doesn't
care about binding, it just changes things like cgroups).
- Mail original -
> De: "Samuel Thibault" <samuel.thiba...@inria.fr>
> À: "Hardware locality development list" <hwloc-de...@open-mpi.org>
> Envoyé: Vendredi 29 Juin 2012 22:18:47
> Objet: Re: [hwloc-devel] [hwloc-svn] svn:hwloc r4554 - trunk/ut
I am looking at filtering special characters out of strings to make XML
export/reimport safer when the BIOS contains ugly DMI infos or when the
user sets crazy custom object info strings.
We don't want to waste time with encoding, supporting ascii is enough in
the vast majority of cases. Others
This causes this warning during autogen (only in the v1.4 branch, but I
don't see why):
configure.ac:141: warning: AC_COMPILE_IFELSE was called before
AC_USE_SYSTEM_EXTENSIONS
config/hwloc.m4:24: HWLOC_SETUP_CORE is expanded from...
configure.ac:141: the top level
Moving the line after
Trunk still looks good, and backporting to v1.4 makes the warning go
away, so I am backporting.
Brice
Le 06/07/2012 23:58, Jeff Squyres a écrit :
> Can you try trunk r4574?
>
> ifdef vs m4_ifdef -- I'm not actually sure, so I went with m4_ifdef.
>
>
> On Jul 6, 2012, at 4:3
I am preparing a v1.5rc1 release, so here's the current status in case
somebody wants to comment.
Major changes for is v1.5:
* instruction caches
* lstopo becomes lstopo + lstopo-no-graphics
* improvements to misc backends (AIX, FreeBSD)
Full v1.5 NEWS list:
* Backends
+ Do not limit the
Sure, it's this NEWS item:
+ Do not limit the number of processors to 1024 on Solaris anymore.
Brice
Le 11/07/2012 04:30, TERRY DONTJE a écrit :
> Is this also going to include the topology_solaris.c improvements?
>
> --td
>
> On 7/10/2012 3:16 PM, Brice Goglin wrote:
&g
e to manually insert hello.c in the README in place
of the doxygen-generated code.
Brice
Le 16/07/2012 15:13, svn-commit-mai...@open-mpi.org a écrit :
> Author: bgoglin (Brice Goglin)
> Date: 2012-07-16 09:13:45 EDT (Mon, 16 Jul 2012)
> New Revision: 4619
> URL: https://svn.open-mpi
Le 23/07/2012 13:40, Pavan Balaji a écrit :
>
> 2. The change to autogen.sh is required for pgcc and friends. You
> can't take this patch as is, obviously, but you'll need some version
> of this. Cc'ing Dave, in case you need more details of this issue.
I haven't tried pgcc recently. Which pgcc
Le 23/07/2012 18:40, Pavan Balaji a écrit :
>
>>> 3. The changes to config/hwloc.m4 and include/private/private.h are
>>> essentially a warning squash when getpagesize() requires an explicit
>>> prototype declaration. But it's not clear how easy it is for you to
>>> absorb it as it uses an MPICH2
Antoine Rougier finished his internship recently so here's a summary of
what he did in the "backends" branch. For the record, the goal of his
work was to explore how to change our backends into proper plugins so
that we can easily avoid hard dependencies between the hwloc core and
external
Le 07/08/2012 13:06, Jeff Squyres a écrit :
>> Aside from the main "discover" callback, backends may also define some
>> callbacks to be invoked when new object are created. The main example is
>> Linux creating "OS devices" when a new "PCI device" is added by the PCI
>> backend. CUDA could use
I got some positive feedback from the user who requested what's in the
"valarray" branch so I am planning to include it in v1.6.
For the record, it's about annotating objects with randoms values.
Before that, we can annotate objects with strings only ("info"). This
adds a structure containing a
ers of the software stack to save
> their own custom values without collisions, while the void* make a good
> generalization of the stored information.
>
> George.
>
>
>
> On Aug 24, 2012, at 7:09, Brice Goglin <brice.gog...@inria.fr> wrote:
>
>> Le 24
Le 24/08/2012 15:20, Jeff Squyres a écrit :
> I was thinking more like:
>
> struct annotation {
> char *name;
> int array_len;
> enum { INT, LONG, FLOAT, DOUBLE } value_type;
> union {
> int *i_values;
> long *l_values;
> float *f_values;
> double *d_values;
> /*
Le 24/08/2012 23:44, Jeff Squyres a écrit :
> On Aug 24, 2012, at 5:17 PM, George Bosilca wrote:
>
>>> hwloc_obj_t already has a "void *userdata" for this. But we cannot store
>>> it in XML unless we know what it contains.
>> Contiguous binary structures with a known size can be stored in a XML
>If so, there's no need for topology-wide
>hwloc_set_topology_userdata_blob_callback(), the application gives the
>right callbacks when it adds the (key,data) pair.
Forget about this last sentence. We cannot set per object import callback in
advance since objects are not imported yet. The
(breaking the thread since we're far from valarrays now).
I've played with this idea and came with the attached interface change.
Aside from low-level backend changes, everything was very easy to implement.
Let's take an example. I modified lstopo to add some userdata to the
root object and
tle odd to pass the "reserved" context
> through. Is that some internal XML state? Can that be hidden somewhere
> else, on the topo or the obj?
>
> But that's a minor quibble.
>
>
> On Aug 26, 2012, at 5:52 AM, Brice Goglin wrote:
>
>> (breaking the thread since w
FYI, the components branch seems (almost) in good shape.
OS support status:
* Linux OK
* Solaris OK
* AIX: configure aborts if you --enable-plugins because libltdl is known
to be broken. One guy is working at fixing libltdl. We may reenable this
later.
* Windows fails to link because hwloc
Le 05/09/2012 17:08, Jeff Squyres a écrit :
> On Sep 5, 2012, at 10:23 AM, Samuel Thibault wrote:
>
>>> The problem I was trying to fix below is that linking hwloc plugins on
>>> Darwin failed because plugins referred to hwloc-core symbols. Nothing on
>>> the libtool command-line said where to
Le 06/09/2012 07:23, Pavan Balaji a écrit :
>
> On 09/06/2012 12:22 AM, Brice Goglin wrote:
>> No, we didn't apply anything to v1.5. In trunk, we're using sysconf
>> instead of getpagesize when it supports SC_PAGESIZE or SC_PAGE_SIZE
>> (very often).
>
> Is this going
Le 05/09/2012 18:05, Brice Goglin a écrit :
> Le 05/09/2012 17:23, Jeff Squyres a écrit :
>> On Sep 5, 2012, at 11:12 AM, Brice Goglin wrote:
>>
>>>> To be clear: we have exactly the same situation in OMPI, and we do not
>>>> link any of our DSOs against
:
> Author: bgoglin (Brice Goglin)
> Date: 2012-09-11 07:29:01 EDT (Tue, 11 Sep 2012)
> New Revision: 4825
> URL: https://svn.open-mpi.org/trac/hwloc/changeset/4825
>
> Log:
> Merge trunk up to r4824 into components branch
>
> This is an attempt to svn merge with git merge
Le 05/09/2012 17:42, Jeff Squyres a écrit :
> On Sep 5, 2012, at 11:36 AM, Samuel Thibault wrote:
>
>>> 1. We do not allow "./configure --enable-static --enable-shared". Even
>>> though that's valid Automake/Libtool (i.e., it'll generate libhwloc.a *and*
>>> libhwloc.so), we don't allow it.
>>
I am thinking of merging the components branch in trunk and start
thinking about doing a v1.6 for SC.
For the record the components branch contains:
1) A rework of the backend infrastructure to make the core much more
readable (basically all changes in *.[ch] files). Now we add new
backends by
Le 25/09/2012 01:42, Samuel Thibault a écrit :
>> 2) Plugin support
> One thing that doesn't seem implemented yet is to choose another OS core
> plugin, e.g. to use x86 detection on Linux instead of /proc or /sys
> detection. This will be the same kind of thing with likwid / servet
> -based OS
Le 25/09/2012 08:43, Samuel Thibault a écrit :
> Brice Goglin, le Tue 25 Sep 2012 07:41:48 +0200, a écrit :
>> Le 25/09/2012 01:42, Samuel Thibault a écrit :
>>>> 2) Plugin support
>>> One thing that doesn't seem implemented yet is to choose another OS core
>>
Le 25/09/2012 09:26, Brice Goglin a écrit :
> On most OS, we already have multiple "core os" components, one native
> (linux, ...) with priority 10 and the "noos" one with priority 0. If
> nothing forces a specific component in the list (no env variable, no
&g
Le 25/09/2012 09:49, Samuel Thibault a écrit :
> One thing which can be confusing for the user is that core_linux goes
> to the core os list while core_libpci goes to the additional list. It
> would probably be better to use a different class name. I actually don't
> currently understand what
Le 25/09/2012 10:48, Samuel Thibault a écrit :
> Le 25/09/2012 09:49, Samuel Thibault a écrit :
>>> One thing which can be confusing for the user is that core_linux goes
>>> to the core os list while core_libpci goes to the additional list. It
>>> would probably be better to use a different class
Hello,
hwloc v1.6 won't be ready soon so I am planning to release a 1.5.1 to
flush all pending bug fixes. We still have two freebsd issues to figure
out (Sebastian Kuzminsky's wrong topo on dual E5, and a
segfault/regression spotted by our local testing infrastructure), but I
don't expect many
Le 09/10/2012 21:22, Guy Streeter a écrit :
> /sys/bus/pci/devices/:00:1f.2/ata1
> /sys/bus/pci/devices/:00:1f.2/ata1/host0
> /sys/bus/pci/devices/:00:1f.2/ata1/host0/scsi_host
Ok, host0 was outside of ata1 in earlier kernels. That changed in 3.3
(commit
The attached patch should help (and fix minor bugs nearby).
Brice
2012 10:02:55 -0600
De :Sebastian Kuzminsky <s...@lineratesystems.com>
Pour : Brice Goglin <brice.gog...@inria.fr>
Ok, it's our fault, sort of.
We use cpusets, and by default on this hardware CPUs 0-9 are denied to
most processes (including lstopo). If I explicitly chang
I think I would rather do something like below, to make sure we only
modify the cpuset while discovering things.
The code builds fine on FreeBSD9 and seems to work, but my testing of
changing cpuset doesn't seem to work very well so I'd like a bit more
testing.
Brice
Index:
I committed (a better version of) this to trunk today. hwloc v1.6 should
work fine in your case. I didn't backport into v1.5.1 because I can't be
100% confident that I am not breaking some cases here. We'll see.
Brice
Le 11/10/2012 23:14, Brice Goglin a écrit :
> I think I would rather
Le 15/10/2012 21:52, Guy Streeter a écrit :
> When I'm trying to visualize how my system is physically configured, in order
> to decide how best to bind applications, I'd like to know about every source
> of interrupts. keyboard and mouse, timers, sound, USB-connected devices, etc.
> Has any
I pushed big changes to the components in the last days (what came from
last month discussion + recent CPUModel feature requests).
Now we ombine information from multiple "cpu" backends. For instance the
x86 backend will add socket CPUModel to what native OS backends did.
Aside from
Hello Ralph,
I am not very familiar with these features. What system mechanism do you
currently use for this? Linux cgroups? Any concrete example of what you
would like to do?
Brice
Le 02/11/2012 22:12, Ralph Castain a écrit :
> Hi folks
>
> We (Greenplum) have a need to support resource
Le 06/11/2012 23:55, Guy Streeter a écrit :
> On 11/06/2012 03:53 PM, Brice Goglin wrote:
>> Hello Guy,
>>
>> I don't think OS devices ever had a cpuset. All objects that are not
>> things where you can bind processes usually have NULL cpusets. So when
>> you hav
Hello,
If you're attending SC12, feel free to come to the Inria booth (#1209)
and say hello. Samuel and I will be there, happy to meet people in real
life.
Brice
301 - 400 of 616 matches
Mail list logo
