Fixed, thanks a lot!
Brice
Le 09/02/2011 21:50, Guy Streeter a écrit :
> else if (!strncmp(argv[1], "interleace", 2))
> should be
> else if (!strncmp(argv[1], "interleave", 2))
>
> --Guy
> ___
> hwloc-devel mailing list
>
Here's a draft of patch to add the ability to know where a thread/proc
is currently running [39]
If we only support single threads, we can return a single CPU number. If
we support multithreaded processes, we must return multiple numbers. So
I am returning a cpuset here.
The API (get_cpuexec and
Le 07/02/2011 15:40, Bernd Kallies a écrit :
> When setting HWLOC_IGNORE_DISTANCES=1, hwloc-1.1 does not crash on this
> machine, but produces a somehow unusual topology.
Unusual but not so wrong given what the OS/BIOS says.
> Btw. the same topology
> error is got when applying a trivial fix to
Le 07/02/2011 14:34, Bernd Kallies a écrit :
> Hallo,
>
> we currently have some large SMP systems (SGI Ultraviolet, 64 NUMA nodes
> and 1024 logical procs per OS instance).
> After reboot of one of them, the system came up with memory of one node
> missing. In particular, one of the pseudo
>
Le 04/02/2011 11:56, Samuel Thibault a écrit :
>> + if (topology->flags & HWLOC_TOPOLOGY_FLAG_RESTRICT_TO_BINDING) {
>> +hwloc_cpuset_t cpuset = hwloc_bitmap_alloc();
>> +int err = hwloc_get_cpubind(topology, cpuset, HWLOC_CPUBIND_THREAD);
>> +if (!err)
>> +
Le 03/02/2011 17:12, jsquy...@osl.iu.edu a écrit :
> Author: jsquyres
> Date: 2011-02-03 11:12:32 EST (Thu, 03 Feb 2011)
> New Revision: 3145
> URL: https://svn.open-mpi.org/trac/hwloc/changeset/3145
>
> Log:
> Move two header files:
>
> * include/private/config.h ->
Anybody against getting the distances branch into trunk?
Brice
Le 21/01/2011 18:31, Bernd Kallies a écrit :
>>> hwloc_bitmap_list_sscanfparses a list format cpuset ASCII string
>>> hwloc_bitmap_list_sprintf outputs a list format cpuset ASCII string
>>>
>> I guess these could be added to the C API?
>>
> Brice said that he tries to add the
Le 20/01/2011 22:16, Pavan Balaji a écrit :
> Hi all,
>
> One of the patches that we maintain in MPICH2 for hwloc is to disable
> picking stricter compiler options based on the fact that a ".svn" or
> ".hg" is available. This is similar to disabling picking verbose mode
> based on .svn or .hg
Le 20/01/2011 15:52, Jeff Squyres a écrit :
> On the trunk, we have apparently dropped the .sh extension from
> hwloc-gather-topology. But on the v1.1 branch, it's hwloc-gather-topology.sh.
>
> The NEWS file discusses changes to hwloc-gather-topology.sh in 1.1.1 (the .sh
> version was added in
Le 20/01/2011 13:26, Jeff Squyres a écrit :
> I used my Mac, which I've used to make all the other hwloc tarballs.
>
> I know that doxygen had been updated since I built the 1.1 tarball, though --
> it's possible that the others have been updated, too. I'll check.
>
> Did you notice the font
Le 18/01/2011 19:38, Bernd Kallies a écrit :
> max_os_index = 512, HWLOC_BITS_PER_LONG = 64, rounding gives
> max_os_index = 576.
>
> I also saw the same behaviour on a much smaller machine (usual 2-socket
> Nehalem-EP). CONFIG_NODES_SHIFT is not found in /proc/config.gz.
> max_os_index = 64,
Le 18/01/2011 17:40, Bernd Kallies a écrit :
> Hallo,
>
> I'm using hwloc-1.1 on Linux 2.6.32.19 (x86_64) on a machine that has
> several NUMA nodes. It seems to me that there are unwanted bits left in
> the nodeset "set", when calling hwloc_get_membind_nodeset(topo,
> set, ...) after a successful
Le 12/01/2011 13:16, Samuel Thibault a écrit :
> Thanks for the summary!
>
> Brice Goglin, le Tue 11 Jan 2011 17:38:00 +0100, a écrit :
>
>> More thinking needed here, and it may make us revise the
>> "latency" names in the above "struct hwloc_distances
Le 14/01/2011 23:08, Jeff Squyres a écrit :
> On Jan 11, 2011, at 5:19 PM, Brice Goglin wrote:
>
>
>>> When memory binding to nodesets or cpusets, do bit locations correspond to
>>> hwloc logical values or physical (os_index) values?
>>>
>&g
Le 05/01/2011 17:13, Samuel Thibault a écrit :
> Jeff Squyres, le Wed 05 Jan 2011 15:06:05 +0100, a écrit :
>
>> On Jan 5, 2011, at 8:58 AM, Jeff Squyres wrote:
>>
>>
Actually, it's usually only supported for read-only data.
>>> I'm not sure what you mean -- if this
Le 04/01/2011 12:50, Bernd Kallies a écrit :
> Dear all,
>
> the current bitmap API of hwloc 1.1 supports input/output for bitmaps
> using strings that represent a map as hex words. The functions are
> hwloc_bitmap_snprintf, hwloc_bitmap_sscanf and the like.
>
> Linux cpusets in addition support
Le 22/12/2010 15:59, Guy Streeter a écrit :
> On 12/22/2010 02:36 AM, Brice Goglin wrote:
>> I'll backport this in 1.1 later, in case somebody wants to fix the
>> English speaking.
>>
>> Brice
>>
>
> For the benefit of the Perl and Python bindings effort
I'll backport this in 1.1 later, in case somebody wants to fix the
English speaking.
Brice
Le 22/12/2010 09:28, bgog...@osl.iu.edu a écrit :
> Author: bgoglin
> Date: 2010-12-22 03:28:55 EST (Wed, 22 Dec 2010)
> New Revision: 2975
> URL: https://svn.open-mpi.org/trac/hwloc/changeset/2975
>
>
Le 21/12/2010 09:37, Samuel Thibault a écrit :
> Brice Goglin, le Tue 21 Dec 2010 08:36:28 +0100, a écrit :
>
>> Le 21/12/2010 00:37, Jiri Hladky a écrit :
>>
>>> Regarding the naming. I would argue that since the utility is
>>> currently
Le 21/12/2010 00:37, Jiri Hladky a écrit :
> Regarding the naming. I would argue that since the utility is
> currently called
> hwloc-gather-topology.sh
> then the man page should be named
> hwloc-gather-topology.sh.1
>
> What's your opinion?
Fine with me. I wasn't sure because you originally
Le 20/12/2010 20:06, Guy Streeter a écrit :
> I decided I should just give you the whole output.
Thanks. Indeed, it's a Linux "feature". When you request a non-strict
memory binding in Linux (MPOL_PREFERRED, not MPOL_BIND), it only keeps
the first node in the input nodemask. Instead of allocating
Le 20/12/2010 19:40, Guy Streeter a écrit :
> Get this singlethreaded process memory : expected 0x000f, got
> 0xf...f
>
> Is that a bug?
> That's on my Fedora 13 non-numa system.
This is kind of expected. 0x000f means all the cores in the machine.
0xf...f means all the machine when the
! -w "$dirname" ] ; then
+echo "$dirname is not writable."
+exit 1
+fi
+
destdir=`mktemp -d`
# Use cat so that we properly get proc/sys files even if their
commit 14ecc22a781c6a9d4f34422dfbc8f28693e8073c
Author: Brice Goglin <bgog...@inria.fr>
List-Post: hwloc
Le 19/12/2010 23:30, Jiri Hladky a écrit :
> In the current version (1.1), hwloc-gather-topology.sh is not very robust:
hwloc-gather-topo already changed in trunk since the 1.1 release
unfortunately, I need to see if your changes still apply. Apart from
that, it should be ok for trunk.
However I
Le 18/12/2010 23:53, Jiri Hladky a écrit :
> Hi,
>
> I have seen the same issue with the legend. See attached picture.
>
> Does the fix resolve this issue as well?
I don't think so. Determining the required box width is hard, so most of
the code is actually using some guess.
Fortunately, your
Le 16/12/2010 02:29, Christopher Samuel a écrit :
> make check fails on our CentOS 5.4 box:
We can safely ignore this failure. Can you change the exit line at the
end of tests/linux/gather/test-gather-topology.sh.in into "exit 0",
reconfigure and rerun make check to see if anything else fails?
Le 15/12/2010 14:45, Bernd Kallies a écrit :
> The CPAN thing is the third implementation, which works with objects and
> accessor methods. It is as fast as the first implementation, and perl
> code looks almost like C code (except that it is not possible now to
> compare the hwloc_obj perl
Le 15/12/2010 11:14, Bernd Kallies a écrit :
> Dear all,
>
> the Perl module Sys::Hwloc is available via CPAN, see
>
> http://search.cpan.org/~bka/Sys-Hwloc-0.04/
>
> Comments are welcome.
>
> Ciao BK
>
>
I am not very familiar with Perl packaging, but at least I like the
syntax in the
Le 14/12/2010 20:02, Jiri Hladky a écrit :
> I have only one nice-to-have: move from ctime->strftime (already
> discussed)
>
> And one small comment regarding ./lstopo help message
> --no-legend Remove the text legend at the bottom
>
> Since ./lstopo legend is active only for the
Le 14/12/2010 14:55, Jeff Squyres a écrit :
> BTW, I never replied to the earlier message, but I read over the FAQ text
> that was added to the doxy and it looks good.
>
> Do we like 1.1rc4?
>
I tested about ten machines with various distro/versions on
amd64/i386/ia64. I didn't find any
Following a recent discussion about hwloc being slow on large machines,
I tried to write some doc talking about it and about XML import/export.
Didn't know where to put it, so I added a FAQ section at the end of the
doxy pages. Patch attached.
Brice
Index: doc/hwloc.doxy
Le 08/12/2010 18:02, Brice Goglin a écrit :
> Do you have ppc64-full-with-smt.xml ? I miss this one to regenerate the
> ppc PNGs (and update HACKING too).
>
I managed to create the corresponding XML. If all this looks ok, we just
need to backport commits r290[6789] in v1.1 and do rc4.
Brice
Le 08/12/2010 17:58, bgog...@osl.iu.edu a écrit :
> Author: bgoglin
> Date: 2010-12-08 11:58:49 EST (Wed, 08 Dec 2010)
> New Revision: 2907
> URL: https://svn.open-mpi.org/trac/hwloc/changeset/2907
>
> Log:
> Add dudley/hagrid/emmett XML outputs
> Update those PNGs to the latest lstopo outputs
>
Le 08/12/2010 10:41, Nathalie Furmento a écrit :
> I would rather go for a solution like this:
>
> Node L#1 (P#0)
> Socket L#1
> PU L#2 (P#3)
>
> to be more homegeneous.
Thanks, I think I like it. I'll commit something like that unless
somebody complains by tomorrow.
Brice
Le 03/12/2010 21:42, Bernd Kallies a écrit :
>> We should really encourage people to use XML in such cases. Setting
>> HWLOC_XMLFILE=/path/to/exported/file.xml in the environment should just
>> work (as long as you update the XML file major hwloc releases or os).
>> Maybe we should add a dedicated
Le 02/12/2010 22:25, Bernd Kallies a écrit :
>
>> Do you have any feel for if there are particular bottlenecks in hwloc /
>> lstopo that make it take so long? I wonder if we should just attack those
>> (if possible)...? Samuel and Brice have done all the work in the guts of
>> the API, so
nks for your effort and reply.
>
> I am not see any wrong output, the confusion is just from the code
> reading of “src/topology-x86.c”.
>
> I will trace hwloc to understand its working flow in more detail.
>
> Thanks very much.
>
> Wei Lin
>
> *发件人:* Brice Goglin [m
Hello Wei Lin,
The x86 indeed needs regular updates to support latest processors. But
this x86 backend is mostly only useful if you're using an operating
system that does not export topology information. If you're using Linux,
a recent kernel should already tell hwloc everything you need, and the
Le 30/11/2010 15:20, Jeff Squyres a écrit :
> On Nov 30, 2010, at 9:17 AM, Brice Goglin wrote:
>
>
>> I discussed with some "random" people about the "p" prefix in physical
>> mode. It's not clear whether removing it from the graphical output is a
>&g
Le 30/11/2010 15:03, Jeff Squyres a écrit :
> On Nov 30, 2010, at 8:50 AM, Samuel Thibault wrote:
>
>
>>> 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
Le 24/11/2010 10:31, Pavan Balaji a écrit :
> Folks,
>
> We are maintaining a few patches for hwloc within mpich2. I have just
> updated to 1.1rc3, and wanted to pass them through you guys to see if
> (1) these are still relevant, and (2) if they can be merged upstream.
>
> 1. Gracefully abort at
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 text.
Also, is everybody ok with the new defaults and formatting:
*
Le 24/11/2010 07:58, Christopher Samuel a écrit :
> On 24/11/10 17:47, Christopher Samuel wrote:
>
> > I can get the free(fullmask); to not fail if I comment out
> > the memset() and migrate_pages() calls. If I just comment
> > out the migrate_pages() then it still fails so there's
> > something
Le 24/11/2010 07:47, Christopher Samuel a écrit :
> On 22/11/10 07:48, Christopher Samuel wrote:
>
> > *** glibc detected *** /tmp/hwloc/hwloc-1.1rc2/tests/.libs/hwloc_bind:
> > free(): invalid next size (fast): 0x1001c240 ***
>
> Went and had a look at the code that was failing. This is
> the
We could also print a message in stdout:
"Using physical/OS indexes by default in the graphic mode, use -l to
revert to logical indexes"
Anybody that may confuse logical/physical indexes will have to run
hwloc-calc/bind from a terminal anyway, so printing this lstopo message
to the terminal may
Le 22/11/2010 14:17, Jeff Squyres a écrit :
> Guys --
>
> I see some requests to make RC's in the middle of the thread with Chris, but
> it wasn't entirely clear to me that the problems had actually been fixed.
>
> Do you still want me to make the next RC's?
>
>
I think 1.0.3 is good to go. I
Le 21/11/2010 22:04, Christopher Samuel a écrit :
> On 22/11/10 07:53, Brice Goglin wrote:
>
> > It looks like what we fixed in r2773 (committed after
> > rc2 iirc). Patch attached.
>
> Hmm, no joy I'm afraid, confirmed it applied and did
> a make distclean; ./configu
Le 21/11/2010 21:48, Christopher Samuel a écrit :
> On 22/11/10 07:33, Brice Goglin wrote:
>
> > This patch (on top of the previous patch) should make
> > hwloc-gather-topology.sh work again (and make check too,
> > hopefully).
>
> Well that fixed that part, "pa
stat: No such file or directory
>>
> Ok, I'll fix those.
>
This patch (on top of the previous patch) should make
hwloc-gather-topology.sh work again (and make check too, hopefully).
Brice
commit e0826ecff1484574bde89ad6695d0f7b5a62f6a2
Author: Brice Goglin <bgog...@inria.fr&g
Here's the patch :)
Le 21/11/2010 20:49, Brice Goglin a écrit :
> Le 21/11/2010 20:34, Christopher Samuel a écrit :
>
>> In look_powerpc_device_tree() I did similar and found that it
>> never proceeds past this loop:
>>
>> if (('.' == dirent->d_name[0])
Le 21/11/2010 20:34, Christopher Samuel a écrit :
> In look_powerpc_device_tree() I did similar and found that it
> never proceeds past this loop:
>
> if (('.' == dirent->d_name[0]) || (0 == (dirent->d_type & DT_DIR)))
> continue;
>
> Adding some debugging to print the name and type and
Le 21/11/2010 20:03, Christopher Samuel a écrit :
> On 22/11/10 05:45, Christopher Samuel wrote:
>
> > I'll try applying the same patch to the x86-64 build and doing
> > a --enable-debug build there and compare them.
>
> Looking at the strace and the source seems to show that
> both builds enter
Le 19/11/2010 22:39, Guy Streeter a écrit :
> Has anyone worked on or expressed interest in python bindings for the
> hwloc library? I do most of my work in python and would find it useful.
> I threw together a python implementation of the hwloc-hello program
> in python, using ctypes to access
Le 18/11/2010 16:58, Samuel Thibault a écrit :
> 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
Le 18/11/2010 08:50, Jirka Hladky a écrit :
> Hi all,
>
> Red Hat would like to included hwloc in the upcoming version of the Red Hat
> Enterprise Linux 6.1. There is Bugzilla 648593
> [RFE] Include Portable Hardware Locality (hwloc) in RHEL
>
> https://bugzilla.redhat.com/show_bug.cgi?id=648593
Hello Chris,
It's not in trunk yet. Try this branch instead:
https://svn.open-mpi.org/svn/hwloc/branches/libpci
We are not sure yet how we should expose all these devices. Right now,
we have a new BRIDGE type, a PCI_DEVICE type, and a OS_DEVICE type
(which corresponds to OS names such as eth0
Le 16/11/2010 15:18, Samuel Thibault a écrit :
> Jirka Hladky, le Tue 16 Nov 2010 21:37:01 +0100, a écrit :
>
>> There was some discussion about hwloc-distrib --among
>>
>> If I understand it correctly, --among accepts one of
>> {pu,core,socket,node,machine}
>>
> I actually didn't know
Le 11/11/2010 13:08, Jirka Hladky a écrit :
> On Thursday, November 11, 2010 11:11:31 am Brice Goglin wrote:
>
>> Le 11/11/2010 02:31, Samuel Thibault a écrit :
>>
>>>> get_mempolicy: Invalid argument
>>>> hwloc_get_membind failed (errno 22 Invalid
Le 11/11/2010 02:31, Samuel Thibault a écrit :
>> get_mempolicy: Invalid argument
>> hwloc_get_membind failed (errno 22 Invalid argument)
>>
>
> Could you try to increase the value of max_os_index?
>
> I can see in the kernel source code the following in sys_get_mempolicy:
>
> if (nmask
Le 10/11/2010 14:09, Jirka Hladky a écrit :
> Hi Brice,
>
> I have found couple of issues with 1.1rc2
>
> 1) man hwloc-bind
> Following example does not work:
> $ hwloc-bind --cpubind node:1 --membind:0 echo hello
> Unrecognized option: --membind:0
>
Obvious typo in the manpage (should be
Le 09/11/2010 18:49, Samuel Thibault a écrit :
> That is not a problem here. The attr field of hwloc_obj will be NULL,
> that's all, the application won't ever read it anyway.
>
We will see segfaults if applications were looking at machine->attr
without checking that it's non-NULL. It's a
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 should be
> 1:0:0.
>
I don't think any function behavior changed.
Looks good but you already committed this anyway :)
Brice
Le 08/11/2010 15:17, Jeff Squyres a écrit :
> Short version:
> --
>
> According to Libtool docs, I think the 1.0.3 .so version number should be
> 0:2:0.
>
> Can someone verify/sanity check this?
>
> More details:
>
If you can do both 1.0.3 and 1.1rc2 today, that's fine :) What Samuel
said about API breaks is indeed a good reason for doing a final 1.0.x.
Brice
Le 08/11/2010 14:28, Jeff Squyres a écrit :
> Heh; so we got differing opinions.
>
> My $0.02 is that we should do a final 1.0.3 just to close it
Le 07/11/2010 21:12, Brice Goglin a écrit :
> Le 07/11/2010 20:50, jsquy...@osl.iu.edu a écrit :
>
>> @@ -112,7 +114,7 @@
>> .PP
>> To run on the three first sockets on the second and third nodes:
>>
>> -hwloc-bind node:1-2.socket:0:3 echo hello
&g
Le 05/11/2010 16:28, Jeff Squyres 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?
>
Unless something bad happens with 1.1 and we can't make the final 1.1
before a long time (end of november?), I'd rather
Do we want deprecated attributes for the cpuset API then ? Looks like
we'd have to switch from #define to static inlines to do so.
Brice
Le 04/11/2010 16:51, sthib...@osl.iu.edu a écrit :
> Author: sthibaul
> Date: 2010-11-04 11:51:42 EDT (Thu, 04 Nov 2010)
> New Revision: 2696
> URL:
Le 31/10/2010 23:17, Jirka Hladky a écrit :
> 1) During install, rename gather-topology.sh on hwloc-gather-topology.sh
>
I don't know how to rename properly during install with automake, so I
just renamed everywhere (source, build and install dir).
> 2) During install, remove variable
Le 30/10/2010 00:55, Jirka Hladky a écrit :
>
> > >> L2 and one L1 per core. Your machine has hyperthreading, so our
>
> > >> This work-around worked fine on old itaniums since they had one
> L3, one
>
> > >> work-around creates one L3 per thread, while L1 and L2 (properly
>
> > >> reported by the
Le 31/10/2010 01:44, Jirka Hladky a écrit :
> Hi all,
>
> since gather-topology.sh is nice script to help debug problems I was thinking
> to add it to the rpm.
>
> However, path to the lstopo is set to the absolute build path:
>
>
Le 30/10/2010 00:01, Jirka Hladky a écrit :
> On Friday, October 29, 2010 10:59:25 pm Brice Goglin wrote:
>
>> Le 29/10/2010 21:57, Jirka Hladky a écrit :
>>
>>> Hi Samuel,
>>>
>>> I have attached the output of
>>> tests/li
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 simplify many things.
Brice
Le 28/10/2010 10:09,
Anybody against the topic ?
Brice
It's been 3 weeks since we discussed the membind interface. How far are
we from an acceptable API? Is there anything missing apart from
documentation updates? Should I revert the cpumembind stuff?
I'd like some feedback about the distance API too. The internal
implementation isn't perfect yet,
Le 05/10/2010 10:24, Brice Goglin a écrit :
> Thinking more about it, I don't know if it's a good idea. The
> alternatives for the value of a nodeset containing the whole memory when
> there are no NUMA nodes are:
> 1) full nodeset (current behavior). The behavior is thus different i
Le 28/09/2010 11:29, Samuel Thibault a écrit :
> 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 ?
>>
Le 28/09/2010 10:26, Ashley Pittman a écrit :
> On 28 Sep 2010, at 07:27, Brice Goglin wrote:
>
>
>> The bz2 tarball of hwloc 1.0.2 was 2.1MB. hwloc 1.1 will be at least
>> 2.7MB. I know that bandwidth is free, but I am still not confortable
>> with the size incr
at the end of src/cpuset.c
https://svn.open-mpi.org/trac/hwloc/browser/branches/bitmap/src/cpuset.c
Brice
Le 24/09/2010 14:35, Jeff Squyres a écrit :
> Sounds good.
>
> On Sep 24, 2010, at 7:30 AM, Brice Goglin wrote:
>
>
>> Here's a proposal for the new renamed cpuset API
The bz2 tarball of hwloc 1.0.2 was 2.1MB. hwloc 1.1 will be at least
2.7MB. I know that bandwidth is free, but I am still not confortable
with the size increasing that much.
Obviously, the problem comes from tarballs under tests/linux:
605774 28 sept. 08:12 tests/linux/256ppc-8n8s4t.tar.gz
Here's a proposal for the new renamed cpuset API. Non trivial changes
include:
hwloc_cpuset_from_string -> hwloc_bitmap_sscanf
hwloc_cpuset_cpu -> hwloc_bitmap_setonly
hwloc_bitmap_all_but_cpu -> hwloc_bitmap_allbut
My plan would be to:
* commit the attached file as hwloc/bitmap.h
* drop
Le 22/09/2010 16:30, Jeff Squyres a écrit :
> On Sep 22, 2010, at 8:09 AM, Brice Goglin wrote:
>
>
>> hwloc_set_*? hwloc_objset* ? Anything better?
>>
>> hwloc_set_* might not be the best since we would have a hwloc_set_set()
>> function to set one bit :)
>&g
Le 22/09/2010 13:36, Jeff Squyres a écrit :
> On Sep 22, 2010, at 4:38 AM, Brice Goglin wrote:
>
>
>> There are still some problems to solve in the membind branch:
>> * Some OS bind the process too when you bind memory. I see the following
>>
Hello,
hwloc 1.0 was released in May. I think we should release 1.1 before
SC10, which means doing a first RC within a couple weeks.
trunk got many changes since 1.0, but nothing very important. trac says
we're missing memory binding, distances and user-defined process
restrictions. Memory
Le 29/06/2010 11:26, Brice Goglin a écrit :
> Le 29/06/2010 11:15, bgog...@osl.iu.edu a écrit :
>
>> Author: bgoglin
>> Date: 2010-06-29 05:15:57 EDT (Tue, 29 Jun 2010)
>> New Revision: 2257
>> URL: https://svn.open-mpi.org/trac/hwloc/changeset/2257
>>
>&g
Le 16/09/2010 11:00, Alexey Kardashevskiy a écrit :
> On 16/09/10 18:49, Samuel Thibault wrote:
>>
>> Do you perhaps happen to know where it might be on AIX?
>>
>>
>
> No idea, sorry. So what do we do regarding the patch?
We'll likely apply it, we just need to figure out where to put it if
Le 16/09/2010 06:10, Alexey Kardashevskiy a écrit :
> Hi!
>
> There are 2 problems with the current HWLOC code. The questions are at
> the bottom.
>
> 1. Old kernels (RHEL5.*) do expose some numa nodes via sysfs but there
> is no information regarting cache (L1/L2/L3) and CPU threads. RHEL6
> does
Le 06/08/2010 15:50, Bernd Kallies a écrit :
> Hallo,
>
> when I create a cpuset manually according to cpuset(7), configuring a
> subset of cpus and mems of the machine for it, bind the current shell to
> this cpuset, and execute lstopo, then I expect that the listed topology
> shows only the
Power7 topology isn't properly reported by old kernels. We've been said
that it works fine with 2.6.34. I am not sure which commit fixed this. I
don't see many commits talk about Power7 topology between 2.6.32 and
2.6.34, so it may be this one (from 2.6.34):
commit
De :Pavan Balaji <bal...@mcs.anl.gov>
Pour : Brice Goglin <brice.gog...@inria.fr>
D'oh! I forgot to forward stderr to the files. I've reattached them.
-- Pavan
On 08/01/2010 04:07 AM, Brice Goglin wrote:
> I don't see any error in your attachments.
>
> Brice
>
Le 29/07/2010 14:59, Jeff Squyres a écrit :
> Jirka --
>
> Just curious: what's Red Hat's plans for hwloc? Will hwloc be in Fedora and
> RHEL? Or will hwloc be an EPEL? Or ...?
>
>
It entered FC12 and FC13 today, and it should be in Redhat EPEL soon.
You can follow things on
> 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.
That's why Group2 matches nothing in reality.
Group3 matches nothing as
Le 28/07/2010 18:53, Brice Goglin a écrit :
> Actually no, but it's very hard to see :)
> lstopo - | egrep "(NUMA|Group)"
> shows that Group4#0 only contains Group3#0 and #1.
> Group3#2 is directly a child of the machine (the indentation is smaller).
>
>
Fo
Le 28/07/2010 20:59, Bernd Kallies a écrit :
> So it seems to me that you basically get a distance matrix of PU objects
>
NUMA node objects actually. That's what Linux and Solaris report.
> from the system (the machine vendor), and probably you do agglomerative
> average linkage cluster
Le 28/07/2010 18:53, Brice Goglin a écrit :
> Distance matrix between Group0 objects:
> 13 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64 66
> 22 13 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64
> 24 22 13 22 24 26 28 30 32 34 36 38 40 42 44 46 48
Le 22/07/2010 19:30, Michael Raymond a écrit :
> /proc/mounts:
> cpuset /dev/cpuset cgroup
> rw,relatime,cpuset,noprefix,release_agent=/sbin/cpuset_release_agent 0 0
>
> The third element there is "cgroup" which the code specifically looks
> for in hwloc_find_linux_cpuset_mntpnt().
>
>
Le 22/07/2010 14:53, Michael Raymond a écrit :
> I was doing some testing on what's in SVN and I found that the
> topology discovery code has a problem when running within a cpuset. On
> my 2.6.32 SLES11SP1 box the code calls hwloc_read_linux_cpuset_mask()
> with a cgroup mount point and tries
Hello,
Somebody just complained to me about our headers not being C++
compliant. Is there anything against adding the usual extern "C" stuff?
Brice
Le 17/07/2010 11:47, Samuel Thibault a écrit :
> bgog...@osl.iu.edu, le Sat 17 Jul 2010 05:05:46 -0400, a écrit :
>
>> +/** \brief Bind current process memory on memory nodes near the given
>> cpuset \p set
>> + *
>> + * \return ENOSYS if the action is not supported
>> + * \return EXDEV if the
k_linux (topology=0x8807008)
> at topology-linux.c:1805
> 1805if (!strcmp(topology->backend_params.sysfs.root_path, "/"))
> (gdb) p topology->backend_params.sysfs
> $1 = {root_path = 0x0, root_fd = -1}
> (gdb)
>
> Need any other info?
>
>
> On Jul 16, 2010,
501 - 600 of 701 matches
Mail list logo
