Αλέξανδρος Παπαδογιαννάκης, le Sat 19 Jun 2010 00:31:59 +0300, a écrit :
> I think the problem is on the kernel.
I'd tend to think the same. I've had a quick look at the differences
between the kernels and potential culprit could be at least cgroup or
priority-inheritance futexes. You should pro
Jirka Hladky, le Sat 19 Jun 2010 00:45:17 +0200, a écrit :
> I haven't tried it yet. In any case, rpath is already in Makefile.in which is
> shipped with hwloc-1.0.1:
>
> ./src/Makefile.in:@HWLOC_BUILD_STANDALONE_TRUE@am_libhwloc_la_rpath = -rpath
> $(libdir)
> ./src/Makefile.in:@HWLOC_BUILD_STA
Jirka Hladky, le Sat 19 Jun 2010 00:45:17 +0200, a écrit :
> I have double checked it.
>
> /usr/lib64 is included in the output of gcc -print-search-dirs.
Just to make sure, in the libtool script, what does the
sys_lib_dlsearch_path_spec variable get set to?
Samuel
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
Αλέξανδρος Παπαδογιαννάκης, le Sat 19 Jun 2010 02:20:37 +0300, a écrit :
> I forgot to ask. Is there a way to get pid_t from a pthread_t?
No :/
Samuel
Samuel Thibault, le Sat 19 Jun 2010 01:30:47 +0200, a écrit :
> Αλέξανδρος Παπαδογιαννάκης, le Sat 19 Jun 2010 02:20:37 +0300, a écrit :
> > I forgot to ask. Is there a way to get pid_t from a pthread_t?
>
> No :/
(but you can use pthread_setaffinity_np)
Samuel
Αλέξανδρος Παπαδογιαννάκης, le Sun 20 Jun 2010 17:31:09 +0300, a écrit :
> Thanks a lot for your help. Seems like the problem is
> only in 2.6.32 kernel, 2.6.33 and 2.6.34 ara working
> fine. I used git bisect like you suggested and the
> problem is on a commit:
>
> sched: Fix a race between t
Αλέξανδρος Παπαδογιαννάκης, le Sun 20 Jun 2010 20:20:28 +0300, a écrit :
> No I didn't :/
Then bounce your mail to it.
Samuel
Αλέξανδρος Παπαδογιαννάκης, le Sun 20 Jun 2010 20:23:34 +0300, a écrit :
> linux-ker...@vger.kernel.org right?
Yes.
Samuel
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 lib
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
Jirka Hladky, le Mon 21 Jun 2010 23:40:14 +0200, a écrit :
> It's dual core CPU with 2x1MB L2 cache. hwloc reports correct result only on
> RHEL6.0 (public beta2) with kernel 2.6.32.
>
> hwloc fails to report correct results on RHEL 5.5 (kernel 2.6.18) and RHEL
> 4.8
> (kernel 2.6.9). Please se
Jirka Hladky, le Mon 21 Jun 2010 23:40:14 +0200, a écrit :
> processor : 0
>
>
> processor : 1
> physical id : 0
> siblings : 2
> core id : 1
> cpu cores : 2
This looks bogus indeed.
Samuel
Hello,
Rupert Brooks, le Thu 22 Jul 2010 09:20:34 -0400, a écrit :
> So i apologize if this question has been asked many times before. Is
> there a way using hwloc (or otherwise) that i can identify which core
> of the machine a thread is currently using?
Hwloc provides a function to get the cur
jay...@mcs.anl.gov, le Fri 17 Sep 2010 14:42:19 -0600, a écrit :
> /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../include/w32api/winspool.h:255:
> error: two or more data
Uh, Xwindow headers #define Status to some type... hacked around in svn,
thanks for the report.
Samuel
Ondrej Marsalek, le Fri 01 Oct 2010 10:56:42 +0200, a écrit :
> I have a question regarding parallelization using both MPI and threads
> in a NUMA setup. I would like to be able to use one MPI process per
> socket or NUMA node and use threads within each MPI process to use all
> the cores. Can I us
Brice Goglin, le Fri 12 Nov 2010 15:18:25 +0100, a écrit :
> My talk on the Cisco booth is Wednesday at 11am. Now I need to find out
> what is the right way to pronounce "hwloc" :)
It's "achedoublevéloque" of course :p
Samuel
Amna Aslam, le Thu 09 Dec 2010 17:54:32 +0100, a écrit :
> I am unable to compile hwloc library on windows 7 x64 edition using CMake. Can
> anyone please help me with compiling this library using CMake or let me know
> what steps to follow.
Mmm, why using cmake? I don't think autoconf/automake su
Hello,
Amna Aslam, le Thu 09 Dec 2010 19:08:21 +0100, a écrit :
> This is for the first time i am using mingw64,
This is the first time for us too actually.
> can you tell me the steps for compiling hwloc using this mingw64.
The same as usual: ./configure && make
> i am getting this error, whe
Samuel Thibault, le Fri 10 Dec 2010 08:12:36 +0800, a écrit :
> Amna Aslam, le Thu 09 Dec 2010 19:08:21 +0100, a écrit :
> > can you tell me the steps for compiling hwloc using this mingw64.
>
> The same as usual: ./configure && make
Apparently the mingw64 website d
guillaume Arnal, le Fri 28 Jan 2011 15:32:40 +0100, a écrit :
> First: I'm looking for a way to find which core is using by the current
> thread.
> (maybe with hwloc_get_thread_cpubind ??)
You mean where the current thread is actually executing, not where it is
just allowed to execute? Hwloc doe
Jim Burnes, le Fri 28 Jan 2011 17:51:00 +0100, a écrit :
> While hwloc might not support it, should your local threading library
> do it? (ie: pthread?)
There's no standard about it. The problem is that the value can be
expired right after you have gotten it, that's probably why nobody
managed to
guillaume Arnal, le Fri 28 Jan 2011 17:42:31 +0100, a écrit :
> Actually, i want to know where my current thread is executing. But is seens to
> be impossible, jeez ...
It's not impossible, it's just not implemented in hwloc (yet).
Samuel
Hendryk Bockelmann, le Wed 09 Feb 2011 16:57:43 +0100, a écrit :
> Since I am new to hwloc there might be a misunderstanding from my side,
> but I have a problem getting the cpuset of MPI tasks.
>/* get native cpuset of this process */
>cpuset = hwloc_bitmap_alloc();
>hwloc_get_cpubin
Hello,
Hendryk Bockelmann, le Thu 10 Feb 2011 09:08:11 +0100, a écrit :
> On our clusters the job scheduler binds the MPI tasks, but it is not
> always clear to which resources. So for us it would be great to know
> where a task runs such that we might adopt the MPI communicators to
> increase
Hendryk Bockelmann, le Thu 10 Feb 2011 11:00:25 +0100, a écrit :
> btw: are there any plans to fully support POWER6 and/or POWER7 running
> AIX6.1 for the future? Actually we can get the topology right but cache
> sizes are missing.
obj->attr->cache.size = 0; /* TODO: ? */
:)
I don't kn
Brice Goglin, le Mon 14 Feb 2011 07:56:56 +0100, a écrit :
> The operating system decides where each process runs (according to the
> binding). It usually has no knowledge of MPI ranks. And I don't think it looks
> at the PID numbers during the scheduling.
It doesn't either, indeed.
Samuel
Brice Goglin, le Thu 31 Mar 2011 22:35:57 +0200, a écrit :
> The Hardware Locality (hwloc) team is pleased to announce the release of
> v1.1.2rc1:
>
> http://www.open-mpi.org/projects/hwloc/
It works fine in all my porting tests.
Samuel
Jeff Squyres, le Sun 10 Apr 2011 13:06:58 +0200, a écrit :
> > It seems that lstopo can get mightly confused with AMD Athlon II processor
> > (family 10h) that doesn't have L3 cache.
Indeed, thanks for the fix! OpenMPI might want to pick up r3418 from the
1.1 branch.
Samuel
Josh Hursey, le Wed 08 Jun 2011 22:28:53 +0200, a écrit :
> I hit a problem when installing hwloc statically on a machine with a
> slightly different gcc support libraries and OSs on the head/compile
> node versus the compute nodes. The builtin functions would cause hwloc
> to segfault when run on
Josh Hursey, le Thu 09 Jun 2011 14:52:39 +0200, a écrit :
> The odd thing about this environment is that the head node seems to
> have a slightly different setup than the compute nodes (not sure why
> exactly, but that's what it is). So hwloc is configured and runs
> correctly on the head node, but
Hello,
Josh Hursey, le Thu 09 Jun 2011 17:03:29 +0200, a écrit :
> Program terminated with signal 4, Illegal instruction.
> #0 0x0041d8d9 in hwloc_weight_long ()
> 0x0041d8d9 : popcnt
> 0xfff8(%rbp),%rax
This is SSE4 indeed. You could check in grep sse4 /proc/c
Hello,
c...@pbspro.com, le Thu 09 Jun 2011 23:33:08 +0200, a écrit :
> I wonder whether anyone could speak about exactly what
> versions of the supporting operating systems we should expect to
> work, particularly specifics about compilation requirements and
> instructions.
Unfortunately
c...@pbspro.com, le Tue 14 Jun 2011 04:18:37 +0200, a écrit :
> The problem is that those symbols are present (on our systems
> at least) in libcurses but not libncurses, which is what the
> HWLOC_TERMCAP_LIBS
> uses (because the search path in config/hwloc_internal.m4 places ncurses
> before
> c
Carl Smith, le Thu 16 Jun 2011 03:05:46 +0200, a écrit :
> that would generate the correct header file to library pairing. In my
> case, the attached patch on top of your previous change did the trick.
But then we'd use curses instead of ncurses on all systems and never
use ncurses, which is a re
Carl Smith, le Tue 21 Jun 2011 00:44:20 +0200, a écrit :
> Seems like it's lstopo-text.c's assumption that /usr/include/term.h is
> appropriate to include with ncurses support that's causing the
> cross-pollution.
Ah, ok. So what fails to link is
/* cc test.c -o test -lncurses */
#include
#incl
Carl Smith, le Tue 21 Jun 2011 02:07:09 +0200, a écrit :
> > Ah, ok. So what fails to link is
> >
> > /* cc test.c -o test -lncurses */
> > #include
> > #include
> > int main(void) {
> > }
> >
> > is that right?
>
> Yes, and
>
> > /* cc test.c -I/usr/include/ncurses -o test -lncurses */
Samuel Thibault, le Tue 21 Jun 2011 02:10:22 +0200, a écrit :
> Carl Smith, le Tue 21 Jun 2011 02:07:09 +0200, a écrit :
> > > Ah, ok. So what fails to link is
> > >
> > > /* cc test.c -o test -lncurses */
> > > #include
> > > #include
> >
Alfredo Buttari, le Tue 05 Jul 2011 20:13:55 +0200, a écrit :
> if I understand correctly this routine can tell on which NUMA node(s)
> a specific memory area resides, is this correct?
Yes.
> Will this routine work on any memory area allocated with any
> allocation routine other than those provid
Carl Smith, le Thu 07 Jul 2011 22:46:07 +0200, a écrit :
> checking ncurses.h usability... yes
> checking ncurses.h presence... yes
> checking for ncurses.h... yes
> checking for term.h... yes
> checking for library containing tparm... -lncurses
> checking curses.h usability... no
> checking curses
Carl Smith, le Fri 08 Jul 2011 01:01:53 +0200, a écrit :
> > Oops, I hadn't realized that AC_CHECK_HEADERS checks for all of them.
> > I've rewritten it quite a bit, in an actually more straightforward way,
> > could you test it?
>
> Sure - still no joy. It's still selecting ncurses.
Ow, A
Carl Smith, le Fri 08 Jul 2011 03:51:07 +0200, a écrit :
> > Alright, I give up trying to use autoconf high-end macros, here is
> > another, low-level try.
>
> Alas, I think this one comes full circle: it's deciding on ncurses,
> then failing the link step.
Uh. That's not coherent:
checki
Carl Smith, le Tue 12 Jul 2011 02:46:27 +0200, a écrit :
> > is it perhaps the presence of -L/usr/local/lib which makes the linking
> > fail? I've commited something that might help.
>
> Perhaps. Your latest change does work on this AIX system. Thanks
> for persisting.
Great!
I've backpo
Erkcan Özcan, le Thu 14 Jul 2011 08:50:54 +0200, a écrit :
> I have been testing hwloc on my macbook (OSX 10.6.8, Core 2 Duo, 4MB L2
> Cache), and the 1.2 version of hwloc is unable to determine the cache sizes
> at all. I had initially used 1.0.3, which was doing fine, and I also tested
> 1.1.2
Erkcan Özcan, le Thu 14 Jul 2011 10:18:53 +0200, a écrit :
> Attached are the output of lstopo with the trunk version and the 1.1.2
> version, along with the output of sysctl hw.
Oops, de-C99-ization missed a sizeof, could you test trunk again?
Samuel
Hello,
Gabriele Fatigati, le Fri 29 Jul 2011 12:43:47 +0200, a écrit :
> I'm so confused. I see couples of cores with the same core id! ( Core#8 for
> example) How is it possible?
That's because they are on different sockets. These are physical IDs
(not logical IDs), and are thus not garanteed
Gabriele Fatigati, le Fri 29 Jul 2011 13:24:17 +0200, a écrit :
> yhanks for yout quick reply!
>
> But i have a litte doubt. in a non SMT machine, Is it better use this:
>
> hwloc_obj_t core = hwloc_get_obj_by_type(topology, HWLOC_OBJ_CORE, tid);
> hwloc_cpuset_t set = hwloc_bitmap_dup(core->cpus
Gabriele Fatigati, le Fri 29 Jul 2011 13:34:29 +0200, a écrit :
> I forgot to tell you these code block is inside a parallel OpenMP region. This
> is the complete code:
>
> #pragma omp parallel num_threads(6)
> {
> int tid = omp_get_thread_num();
>
> hwloc_obj_t core = hwloc_get_obj_by_type(topol
Gabriele Fatigati, le Mon 01 Aug 2011 14:48:11 +0200, a écrit :
> so, if I inderstand well, PU P# numbers are not the same specified as
> HWLOC_OBJ_PU flag?
They are, in the os_index (aka physical index) field.
Samuel
Brice Goglin, le Mon 01 Aug 2011 22:07:33 +0200, a écrit :
> The Hardware Locality (hwloc) team is pleased to announce the first
> release candidate of version 1.2.1
>
> http://www.open-mpi.org/projects/hwloc/
Could someone test on AIX?
Samuel
Hello,
Hendryk Bockelmann, le Tue 02 Aug 2011 10:54:54 +0200, a écrit :
> I will test hwloc-1.2.1rc1r3567.tar.gz in the next days on our POWER6
> cluster running AIX6.1 and report the results to you resp. to the list
Maybe rather wait for next nightly snapshot, as I've just fixed a bug
with xml t
Gabriele Fatigati, le Tue 02 Aug 2011 16:23:12 +0200, a écrit :
> hwloc_set_cpubind(*topology, set, HWLOC_CPUBIND_THREAD | HWLOC_CPUBIND_STRICT
> | HWLOC_CPUBIND_NOMEMBIND);
>
> is it possible do multiple call to hwloc_set_cpubind passing each flag per
> time?
>
> hwloc_set_cpubind(*topology,
Gabriele Fatigati, le Tue 02 Aug 2011 17:13:15 +0200, a écrit :
> $pragma omp parallel num_thread(1)
> {
> hwloc_set_cpubind(*topology, set, HWLOC_CPUBIND_THREAD |
> HWLOC_CPUBIND_STRICT
> | HWLOC_CPUBIND_NOMEMBIND);
> }
>
> is equivalent to?
>
> $pragma omp parallel num_thread(1)
> {
> hwlo
Gabriele Fatigati, le Tue 02 Aug 2011 17:22:31 +0200, a écrit :
> and in this way are equivalent?
>
> #pragma omp parallel num_threads(1)
> {
> hwloc_obj_t core = hwloc_get_obj_by_type(*topology, HWLOC_OBJ_PU, 0);
> hwloc_cpuset_t set = hwloc_bitmap_dup(core->cpuset);
> hwloc_set_cpubind(*topology
Gabriele Fatigati, le Wed 03 Aug 2011 11:05:19 +0200, a écrit :
> -1 with errno set to ENOSYS if the action is not supported
> -1 with errno set to EXDEV if the binding cannot be enforced
>
> What's the difference?
The same as other OS functions: ENOSYS means it's never supported. EXDEV
means it'
Hello,
Gabriele Fatigati, le Mon 01 Aug 2011 12:32:44 +0200, a écrit :
> So, are not physically near. I aspect that with Hyperthreading, and 2 hardware
> threads each core, PU P#0 and PU P#1 are on the same core.
Since these are P#0 and 1, they may not be indeed (physical indexes).
That's the who
Gabriele Fatigati, le Thu 04 Aug 2011 15:52:09 +0200, a écrit :
> how the topology gave by lstopo is built? In particolar, how the logical index
> P# are initialized?
P# are not logical indexes, they are physical indexes, as displayed in
/proc/cpuinfo & such.
The logical indexes, L#, displayed wh
Gabriele Fatigati, le Thu 04 Aug 2011 16:14:35 +0200, a écrit :
> Socket:
> __
> | |
> | |core | |core | |
> | |
> | |core | |core | |
> | |
> | |core
Gabriele Fatigati, le Thu 04 Aug 2011 16:35:36 +0200, a écrit :
> so physical OS index 0 and 1 are not true are physically near on the die.
They quite often aren't. See the updated glossary of the documentation:
"The index that the operating system (OS) uses to identify the object.
This may be co
Gabriele Fatigati, le Thu 04 Aug 2011 16:56:22 +0200, a écrit :
> L#0 and L#1 are physically near because hwloc consider shared caches map when
> build topology?
Yes. That's the whole point of sorting objects topologically first, and
numbering them afterwards. See the glossary entry for "logical i
Gabriele Fatigati, le Tue 09 Aug 2011 16:58:33 +0200, a écrit :
> in a non SMT machine, what's the difference between HWLOC_OBJ_CORE
> and HWLOC_OBJ_PU?
There is no difference concerning the cpuset.
> can I exchange one to other?
If you are absolutely sure that your machine is non SMT, yes. But
Gabriele Fatigati, le Tue 09 Aug 2011 17:04:04 +0200, a écrit :
> >There is no difference concerning the cpuset.
>
> It means they have the same logical index?
Since there is exactly one pu per core and they'll be sorted the same,
yes, by construction they will have the same logical index.
Samue
Gabriele Fatigati, le Tue 09 Aug 2011 18:14:55 +0200, a écrit :
> hwloc_get_cpubind() function, return, according to the manual, "current
> process
> or thread binding". What does it means?
The cpuset to which the current process or thread (according to flags)
was last bound to. That is, the conv
Gabriele Fatigati, le Wed 10 Aug 2011 09:35:19 +0200, a écrit :
> these lines, doesn't works:
>
> set = hwloc_bitmap_alloc();
> hwloc_get_cpubind(topology, &set, 0);
>
> hwloc_get_cpubind() crash, because I have to pass set, not &set i suppose.
Right, of course.
> I think hwloc_get_last_cpu_loc
Gabriele Fatigati, le Wed 10 Aug 2011 15:29:43 +0200, a écrit :
> hwloc_obj_t core = hwloc_get_obj_by_type(topology, HWLOC_OBJ_MACHINE, 0);
>
> int return_value = hwloc_get_last_cpu_location(topology, core->cpuset,
> HWLOC_CPUBIND_THREAD);
>
> and now in "core->cpuset" I get the new cpuset bitmap
Gabriele Fatigati, le Wed 10 Aug 2011 15:41:19 +0200, a écrit :
> hwloc_cpuset_t set = hwloc_bitmap_alloc();
>
> int return_value = hwloc_get_last_cpu_location(topology, set,
> HWLOC_CPUBIND_THREAD);
>
> printf( " bitmap_string: %s \n", bitmap_string[0]);
>
> give me:
>
> 0x0800
>
> conve
Gabriele Fatigati, le Wed 10 Aug 2011 16:13:27 +0200, a écrit :
> there is something wrong. I'm using two thread, the first one is bound on
> HWLOC_OBJ_PU number 2, the second one on HWLOC_OBJ_PU number 10,
It seems that hwloc_linux_get_tid_last_cpu_location erroneously assume
that /proc/self/sta
Samuel Thibault, le Wed 10 Aug 2011 16:24:39 +0200, a écrit :
> Gabriele Fatigati, le Wed 10 Aug 2011 16:13:27 +0200, a écrit :
> > there is something wrong. I'm using two thread, the first one is bound on
> > HWLOC_OBJ_PU number 2, the second one on HWLOC_OBJ_PU number 10
Gabriele Fatigati, le Thu 11 Aug 2011 10:32:23 +0200, a écrit :
> I'm using hwloc-1.3a1r3606. Now hwloc_get_last_cpu_location() works well:
>
> thread 0 bind: 0x0008 as core number 3
> thread 1 bind: 0x0800 as core number 11
Good.
> but hwloc_linux_get_tid_cpubind() has still some p
Gabriele Fatigati, le Thu 11 Aug 2011 18:05:25 +0200, a écrit :
> char* bitmap_string=(char*)malloc(256);
>
> hwloc_bitmap_t set = hwloc_bitmap_alloc();
>
> hwloc_linux_get_tid_cpubind(&topology, tid, set);
Where does "tid" come from? hwloc_linux_get_tid_cpubind() only takes
Linux tids (as in ge
Gabriele Fatigati, le Thu 11 Aug 2011 18:26:28 +0200, a écrit :
> Gabriele Fatigati, le Thu 11 Aug 2011 18:05:25 +0200, a écrit :
> > char* bitmap_string=(char*)malloc(256);
> >
> > hwloc_bitmap_t set = hwloc_bitmap_alloc();
> >
> > hwloc_linux_get_tid_cpubind(&topology, tid
Hello,
PULVERAIL Sébastien, le Fri 12 Aug 2011 13:59:46 +0200, a écrit :
> Does a such function exist ?
See hwloc_get_last_cpu_location()
Samuel
Gabriele Fatigati, le Mon 15 Aug 2011 10:56:49 +0200, a écrit :
> thanks for the info, but it means mbind() function could does not works in
> some
> cases?
No, valgrind just checks the arguments, it does not change the system
call behavior, so it should just work as usual.
Samuel
Wheeler, Kyle Bruce, le Tue 16 Aug 2011 00:11:41 +0200, a écrit :
> I'm having the problem that my Magny Cours system is being identified (via
> hwloc-ls) as sharing an L3 cache between the NUMAnodes on a single socket. I
> know that this is not actually true, and I don't know how to begin debugg
Jeff Squyres, le Tue 16 Aug 2011 16:09:24 +0200, a écrit :
> I'd be against hwloc automatically spreading across multiple machines. I
> think there are plenty of tools to do that already.
I fully agree. There is no way to be able to interact with each and
every job scheduler anyway.
> That bein
Wheeler, Kyle Bruce, le Tue 16 Aug 2011 16:52:54 +0200, a écrit :
> On Aug 15, 2011, at 4:14 PM, Samuel Thibault wrote:
> > Wheeler, Kyle Bruce, le Tue 16 Aug 2011 00:11:41 +0200, a écrit :
> >> I'm having the problem that my Magny Cours system is being identified (via
&g
Wheeler, Kyle Bruce, le Tue 16 Aug 2011 16:52:54 +0200, a écrit :
> hwloc-gather-topology doesn't seem to work on my compute nodes... not sure
> why. It doesn't report any failures, but it doesn't create the tarball either
> (just spits out more lstopo output).
Maybe try to replace /bin/sh with
Brice Goglin, le Tue 16 Aug 2011 19:49:10 +0200, a écrit :
> hwloc 1.2.1 *rc3* is out (web mirrors will update shortly). It fixes
> hwloc_get_last_cpu_location() for Linux threads. Apart from that,
> nothing important. Let's hope this one will become the final 1.2.1
> within a couple days.
Since t
PULVERAIL Sébastien, le Thu 18 Aug 2011 11:55:21 +0200, a écrit :
> I use logical ids, so I do this :
>
> hwloc_obj_t cpu = hwloc_get_obj_by_type(topology,
> HWLOC_OBJ_PU, i);
> int err = hwloc_set_cpubind(topology, cpu->cpuset,
> HWLOC_CPUBIND_THREAD);
>
> Is it
Brice Goglin, le Sun 28 Aug 2011 12:36:31 +0200, a écrit :
> > Is there a hwloc routine to check this?
>
> get_nbobjs_by_type(topology, HWLOC_OBJ_NODE) tells how many NUMA node
> objects exist.
> If you get >1, the machine is NUMA.
> If the non-NUMA case, I think you can get 0 or 1 depending on w
Gabriele Fatigati, le Sun 28 Aug 2011 14:47:33 +0200, a écrit :
> in each case, if get_nbobjs_by_type return 0, also if the machine is NUMA,
> hwloc can't build the NUMA-aware topolog, so the NUMA capability is not
> usable.
> Is it right?
I'm not sure to understand how you relate these statement
Gabriele Fatigati, le Mon 29 Aug 2011 16:16:25 +0200, a écrit :
> hwloc_get_last_cpu_location() return last CPU where process/thread ran.On SMT
> machine, it return the PU where process/thread ran ?
Yes, sure, since what it returns is an OS CPU bitmask.
Samuel
Gabriele Fatigati, le Sat 03 Sep 2011 16:09:11 +0200, a écrit :
> What about hwloc_topology check()?
>
> What types of check does?
Mostly that the hwloc library itself didn't do anything wrong.
Samuel
Gabriele Fatigati, le Mon 12 Sep 2011 15:50:45 +0200, a écrit :
> thanks very much for your explanations. But I don't understand why a process
> inherits core bound of his threads
On Linux, there is no such thing as "process binding", only "thread
binding". hwloc emulates the former by using the l
Brice Goglin, le Thu 22 Sep 2011 14:04:43 +0200, a écrit :
> Le 22/09/2011 12:20, Gabriele Fatigati a écrit :
> > NUMA node(s) near the specified cpuset.
> >
> > What does "nodes near the specified cpuset" means? The node wherethe
> > specified cpuset lives?
> > Set the default memory binding pol
Stefan Eilemann, le Tue 29 Nov 2011 11:40:18 +0100, a écrit :
> Maybe I'm missing something, but I don't see any PCI-related output with
> lstopo.
You are probably missing the libpci-devel package.
Samuel
Andrew Helwer, le Tue 10 Jan 2012 02:08:46 +0100, a écrit :
> First of all, is Windows 64-bit supported? There is only a 32-bit release on
> the downloads page.
I have never tried to build a 64bit binary, but there is little reason
it should fail.
> However, when I specify the --enable-embedded-m
Hello,
Andrew Helwer, le Thu 12 Jan 2012 02:11:58 +0100, a écrit :
> If I run the command manually, it can't find the libhwloc.def file. Which is
> reasonable, as it does not appear to exist in the .lib directory. Am I
> missing something?
In principle the .def file is generated by the linker.
Hello,
Andrew Helwer, le Tue 10 Jan 2012 02:08:46 +0100, a écrit :
> First of all, is Windows 64-bit supported? There is only a 32-bit release on
> the downloads page.
I have tried mingw-w64, and it does seem to work, I have added a 64-bit
release on the download page (pending mirror push).
Samu
Andrew Helwer, le Tue 10 Jan 2012 02:08:46 +0100, a écrit :
> the Visual Studio compiler runs into a lot of issues.
What kind of issues for instance?
Samuel
Andrew Helwer, le Thu 12 Jan 2012 22:52:26 +0100, a écrit :
> C:\hwloc-1.3.1\src>dolib.exe lib.exe X86 .libs/libhwloc.def libhwloc-
> .libs/libhwloc.lib
>
> This creates a .lib file, but when I use the VS compiler to compile and link
> against it, it asks for a dll at runtime.
In mingw terms, .
Andrew Helwer, le Fri 13 Jan 2012 00:11:45 +0100, a écrit :
> > In mingw terms, .lib is meant for dynamic linking, not static linking.
> > the .a file is meant for static linking.
>
> How can I get it to create a static windows lib?
Passing --enable-static to ./configure should do it.
Samuel
Andrew Helwer, le Fri 13 Jan 2012 01:35:27 +0100, a écrit :
> It fails with the following:
>
> *** Warning: linker path does not have real file for library -lgdi32.
Ah, that's a dark bug in libtool.
> gcc -I/cygdrive/c/hwloc-asdf/include -I/cygdrive/c/hwloc-asdf/include
> -I/cygdriv
> e/c/hwloc
Andrew Helwer, le Fri 13 Jan 2012 01:51:15 +0100, a écrit :
> I'm not sure I understand. Can you link to .a files with VS?
I don't know, but what's sure is that .a files are static libraries in
mingw.
> I tried linking to the .lib file in the 64-bit release. I get only unresolved
> external symb
Samuel Thibault, le Fri 13 Jan 2012 02:01:12 +0100, a écrit :
> Andrew Helwer, le Fri 13 Jan 2012 01:51:15 +0100, a écrit :
> > I'm not sure I understand. Can you link to .a files with VS?
>
> I don't know, but what's sure is that .a files are static libraries in
&g
Andrew Helwer, le Fri 13 Jan 2012 18:09:11 +0100, a écrit :
> > You can perhaps try to rename it into a .lib file and give that to VS.
>
> Didn't work.
What errors do you get?
Samuel
Andrew Helwer, le Fri 13 Jan 2012 18:16:16 +0100, a écrit :
> libhwloc.lib(traversal.o) : error LNK2019: unresolved external symbol
> __ms_vsnpr
> intf referenced in function snprintf
Do you also link msvcrt in? mingw needs it for almost everything.
Samuel
Hello,
Marc-André Hermanns, le Mon 16 Jan 2012 14:01:23 +0100, a écrit :
> hwloc_get_last_cpu_location(topology, cpuset, 0);
>
> and I am at a total loss on what I should make of this. It seems I am
> doing something fundamentally wrong,
You need to check the value returned by the function
101 - 200 of 273 matches
Mail list logo
