Hello,
Brock Palen, le Sat 23 Jan 2010 13:51:09 -0500, a écrit :
> System(7870MB)
> Node#0(3906MB) + Socket#0
> L2(1024KB) + L1(1024KB) + Core#0 + P#0
> L2(1024KB) + L1(1024KB) + Core#1 + P#1
> Node#1(4040MB) + Socket#1
> L2(1024KB) + L1(1024KB) + Core#0 + P#2
> L2(1024KB) +
Brock Palen, le Wed 07 Apr 2010 15:52:19 -0400, a écrit :
> has anyone done work with hwloc on scalemp systems?
Not here, but I guess something could be done, yes.
Samuel
Brock Palen, le Wed 07 Apr 2010 16:53:49 -0400, a écrit :
> Sure:
> [root@nyx0809 ~]# cat /sys/devices/system/node/node*/distance
> 10 20 254 254 254 254 254 254
> 20 10 254 254 254 254 254 254
> 254 254 10 20 254 254 254 254
> 254 254 20 10 254 254 254 254
> 254 254 254 254 10 20 254 254
> 254
Brice Goglin, le Mon 26 Apr 2010 17:21:35 +0200, a écrit :
> Maybe adding the spec file to the SVN could be good too?
Possibly, depending on the distribution usages about it.
(In the Debian case for instance, we made it in an independant branch
precisely because of distribution usages).
Samuel
Jirka Hladky, le Mon 26 Apr 2010 17:32:17 +0200, a écrit :
> I'm using it on system without X11 being installed.
>
> I have created it as the starting point to pack hwloc into rpm. What the
> opinion of others - should we add dependency on X11 and sacrify the
> possibility to run hwloc on
Hello,
Currently, we build the whole hwloc for windows as a .zip file. I was
wondering: maybe it'd be cool to also build a standalone lstopo.exe file
that windows admins could keep in the corner of their desktop?
Samuel
Hello,
Αλέξανδρος Παπαδογιαννάκης, le Tue 25 May 2010 02:58:57 +0300, a écrit :
> As you can see hwloc 1.0 doesn't show my L3 and L2 cache while it
> worked fine with hwloc 0.9.3.
Are you able to rebuild a version yourself with debugging enabled to
check the output? On windows 7, the difference
Wheeler, Kyle Bruce, le Tue 25 May 2010 13:02:35 -0600, a écrit :
> I don't see anything in hwloc for determining "distance" between objects in
> the hierarchy. Is there something I'm missing?
Like memory binding, it's in the TODO list :)
Samuel
Wheeler, Kyle Bruce, le Tue 25 May 2010 15:13:51 -0600, a écrit :
> On May 25, 2010, at 2:56 PM, Brice Goglin wrote:
>
> > On 25/05/2010 22:55, Wheeler, Kyle Bruce wrote:
> >> Is the hwloc_topology_t object thread-safe?
> >
> > No, see the thread-safery section in the doc.
>
> Ah. Hm. Good to
Olivier Cessenat, le Sun 06 Jun 2010 15:52:12 +0200, a écrit :
> Couldn't bind to cpuset 0x0002
> >>
> Is hwloc supported on OSX 10.4 platform ?
Yes. But Apple has always beeing refusing to provide binding functions,
so hwloc returns ENOSYS for these.
Samuel
Olivier Cessenat, le Sun 06 Jun 2010 17:37:23 +0200, a écrit :
> I would like to get the cache sizes and hierachy;
> hwloc-ls returns
> <<
> Machine + L1 #0 (0KB)
> PU #0 (phys=0)
> PU #1 (phys=1)
> >>
> which detects my dual core, but not the cache sizes, L2 and L1.
This depends on what the
Olivier Cessenat, le Sun 06 Jun 2010 18:41:26 +0200, a écrit :
> Thank you for the other point; it's in case the sys admin installs with
> --enable-debug, so that the codes that use the API do not get awfully
> verbose.
As its name suggests, --enable-debug was never intended for production
builds
Olivier Cessenat, le Sun 06 Jun 2010 22:44:17 +0200, a écrit :
> By the way, my x86_64 configure says:
> <<
> checking for XML... no
> >>
> I see I have "libxml2-utils" installed... and the --xml mechanism works.
You mean lstopo --xml somefile.xml does not say
This installation of hwloc does not
Wheeler, Kyle Bruce, le Mon 07 Jun 2010 13:00:48 -0600, a écrit :
> True; but you can make each "cpu" a thread set ID.
Ok, that's what I feared :)
The problem is that you don't control _location_ at all, so yes, this
really seems like lying too much :)
Samuel
Αλέξανδρος Παπαδογιαννάκης, le Wed 16 Jun 2010 16:11:12 +0300, a écrit :
> There is no shed affinity call at all if the thread is on a barrier :/
Ok, so since hwloc_set_thread_cpubind returns 0, the issue can only be
in glibc's pthread_setaffinity_np() (and I guess your are calling it on
a thread
Hello,
Alfredo Buttari, le Fri 18 Jun 2010 08:54:35 +0200, a écrit :
> Couldn't bind to cpuset 0xc000,0x0
> --> Error 0
How odd. Could you retry with the latest trunk revision I've just
commited, and also give us the output of make check?
Samuel
Hello,
I agree that rpath should be avoided. However, hwloc itself doesn't add
any.
Jirka Hladky, le Fri 18 Jun 2010 22:09:56 +0200, a écrit :
> =
> hwloc.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/hwloc-distrib
> ['/usr/lib64']
So
Αλέξανδρος Παπαδογιαννάκης, 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
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
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
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
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,
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
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();
>
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
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,
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
> >
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,
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:
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
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 =
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 =
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
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
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?
>
>
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)
> {
>
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);
>
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
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
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
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
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.
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
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, , 0);
>
> hwloc_get_cpubind() crash, because I have to pass set, not i suppose.
Right, of course.
> I think hwloc_get_last_cpu_location()
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
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
>
>
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
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
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(, tid, set);
Where does "tid" come from? hwloc_linux_get_tid_cpubind() only takes
Linux tids (as in gettid()),
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(, tid, set);
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
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
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
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
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
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.
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 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
>
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
Marc-André Hermanns, le Tue 17 Jan 2012 11:47:43 +0100, a écrit :
> It seems now that it has the whole system in the cpuset. How can I
> really infer the PU this process was run on? I would have expected the
> cpuset to have only 1 element per level to indicate the path from
> machine to PU.
Hartmut Kaiser, le Fri 20 Jan 2012 00:43:32 +0100, a écrit :
> > Hartmut Kaiser, le Thu 19 Jan 2012 22:48:50 +0100, a écrit :
> > > We are using hwloc with VS2010 and were happy to realize that after
> > > the (for
> > > us) totally broken Windows binary distribution in V1.3
> >
> > Broken? How
Albert Solernou, le Mon 30 Jan 2012 12:37:31 +0100, a écrit :
> I am working on a threaded code, and want to bind threads to cores. However,
> the process creates and destroys the threads, so here is the question:
> What happens if I enter on a threaded part of the code, bind "thread X" to
> a
Samuel Thibault, le Tue 13 Mar 2012 13:33:05 +0100, a écrit :
> > I tried to recompile the library using MSVC which would allow me to debug
> > the issue, but after several hours of tweaking I gave up. As it turns out
> > the code base is everything but portable, which is
Brice Goglin, le Tue 13 Mar 2012 18:55:29 +0100, a écrit :
> Le 13/03/2012 17:04, Hartmut Kaiser a écrit :
> >>> But the problems I was seeing were not MSVC specific. It's a
> >>> proliferation of arcane (non-POSIX) function use (like strcasecmp,
> >>> etc.) missing use of HAVE_UNISTD_H,
Hartmut Kaiser, le Mon 12 Mar 2012 23:05:44 +0100, a écrit :
> The import library libhwloc.lib distributed with the Windows x64 binaries is
> broken in V1.4.1 (even if it was ok in V1.4). The library internally refers
> to libhwloc-4.dll (instead of libhwloc-5.dll). While it is not a problem to
>
Hartmut Kaiser, le Wed 14 Mar 2012 08:52:59 -0500, a écrit :
>
> > Le 14/03/2012 09:39, Brice Goglin a écrit :
> > > Le 13/03/2012 19:08, Hartmut Kaiser a écrit :
> > >>> - hwloc_bitmap_from_ith_ulong(obj->cpuset,
> > GroupMask[i].Group,
> > >>> GroupMask[i].Mask);
> > >>> +
Samuel Thibault, le Thu 15 Mar 2012 07:42:40 +0100, a écrit :
> Brice Goglin, le Wed 14 Mar 2012 22:32:07 +0100, a écrit :
> > We debugged this in private emails with Hartmut. His 48-core platform is
> > now detected properly. Everything got fixed with a patch
> > functionna
Vlad, le Sat 21 Apr 2012 23:37:11 +0200, a écrit :
> 433 /* take the number of links as a good estimate for the number of tids */
> 434 if (fstat(dirfd(taskdir), ) == 0)
> 435max_tids = sb.st_nlink;
>
> "taskdir" here is /proc//task, correct? In which case the threads will be
> doing
Gabriele Fatigati, le Tue 28 Aug 2012 14:19:44 +0200, a écrit :
> I'm using hwloc 1.5. I would to see how GPUs are connected with the processor
> socket using lstopo command.
About connexion with the socket, there is indeed no real graphical
difference between "connected to socket #1" and
Brice Goglin, le Tue 28 Aug 2012 14:43:53 +0200, a écrit :
> > $ lstopo
> > Socket #0
> > Socket #1
> > PCI...
> > (connected to socket #1)
> >
> > vs
> >
> > $ lstopo
> > Socket #0
> > Socket #1
> > PCI...
> > (connected to both sockets)
>
> Fortunately, this won't occur in most
Jeff Squyres, le Wed 12 Sep 2012 16:16:57 +0200, a écrit :
> He seems to get an hwloc error any time he tries to bind to more than 1 PU.
> Is that expected on Solaris?
Without lgrp support, unfortunately yes: the processor_bind solaris interface
only permits to bind to one processor.
With
I forgot to answer this:
Jeff Squyres, le Wed 12 Sep 2012 16:16:57 +0200, a écrit :
> Sidenote: if hwloc-bind fails to bind, should we still launch the child
> process?
Well, it's up to you to decide :)
Samuel
Jeff Squyres, le Thu 13 Sep 2012 00:45:56 +0200, a écrit :
> On Sep 12, 2012, at 6:42 PM, Samuel Thibault wrote:
> > No, we have it, but not all solaris systems have it.
>
>
> Ah, I see. So if Siegmar had done "hwloc-bind socket:0 ..." -- assuming his
> system
Jeff Squyres, le Thu 13 Sep 2012 00:46:33 +0200, a écrit :
> On Sep 12, 2012, at 6:44 PM, Samuel Thibault wrote:
>
> >> Anyone have an opinion? I'm 60/40 in favor of not letting it run, under
> >> the rationale that the user asked for something that we can't delive
Jeff Squyres, le Thu 13 Sep 2012 17:10:00 +0200, a écrit :
> After a little more thought, I'm also thinking that having a "it's ok if
> binding fails" CLI flag is a bad idea. If the user really wants something to
> run without binding, then you can just do that in the shell:
>
> -
>
Hello,
Sebastian Kuzminsky, le Tue 02 Oct 2012 23:47:05 +0200, a écrit :
> I've attached the output from both platforms.
On freebsd, could you pass --enable-debug to ./configure and rerun
lstopo, to get more debugging information?
Samuel
Hello,
Sebastian Kuzminsky, le Wed 03 Oct 2012 01:08:46 +0200, a écrit :
> Here you go (the list server rejected it because it was too big, but this
> compressed version should make it through).
Thanks!
There were two bugs which resulted into cpuid not being properly
compiled. I have fixed them
Sebastian Kuzminsky, le Wed 03 Oct 2012 17:24:55 +0200, a écrit :
> So that's an improvement over the svn trunk
> yesterday, but it's not all the way fixed yet!
Ok. Apparemently hwloc can't bind itself to procs 0-9 for some reason.
I have added debug to the trunk, could you try it again (no need
Sebastian Kuzminsky, le Sat 06 Oct 2012 00:55:57 +0200, a écrit :
> binding to CPU0
> could not bind to CPU0: Resource deadlock avoided
Mmm, from what I read in the freebsd kernel:
/*
* Create a set in the space provided in 'set' with the provided parameters.
* The set is returned with a
Robin Scher, le Thu 25 Oct 2012 23:39:46 +0200, a écrit :
> Is there a way to get this string (e.g. "Intel(R) Core(TM) i7 CPU M 620 @
> 2.67GHz") consistently on Windows, Linux, OS-X and Solaris?
Currently, no.
hwloc itself does not have a table of such strings, and each OS has its
own table.
Robin Scher, le Thu 25 Oct 2012 23:57:38 +0200, a écrit :
> ; eax = 0x8002 --> eax, ebx, ecx, edx: get processor name string
> (part 1)
> mov eax,0x8002
> cpuid
Oh, this is indeed *exactly* the model name string. I only knew about
the vendor_id string.
> I don't
Olivier Cessenat, le Sat 27 Oct 2012 19:10:55 +0200, a écrit :
> Just in case, I also provide the output of sysctl hw:
Thanks. There is indeed no package information (hw.packages), that's why
hwloc does not include any socket object.
Brice wrote:
> One way to solve this problem (which may also
Brice Goglin, le Mon 05 Nov 2012 23:23:42 +0100, a écrit :
> top can also sort by the last used CPU. Type f to enter the config menu,
> hilight the "last cpu" line, and hit 's' to make it the sort column.
With older versions of top, type F, then j, then space.
Samuel
Hello,
Brice Goglin, le Tue 13 Nov 2012 13:45:28 +0100, a écrit :
> The Hardware Locality (hwloc) team is pleased to announce the first
> release candidate for v1.6:
I'm getting an odd failure in hwloc_pci_backend:
lt-hwloc_pci_backend: hwloc-1.6rc1/tests/hwloc_pci_backend.c:68: main:
Brice Goglin, le Mon 19 Nov 2012 21:09:33 +0100, a écrit :
> hwloc_bitmap_t bitmap = hwloc_bitmap_alloc();
> hwloc_bitmap_set_only(bitmap, i);
> hwloc_set_thread_cpubind(topology, m_threads[i], bitmap, 0);
> hwloc_bitmap_free(bitmap);
Or perhaps
hwloc_set_thread_cpubind(topology, m_threads[i],
Andrew Somorjai, le Tue 20 Nov 2012 01:39:47 +0100, a écrit :
> "CreateThread() and WaitForMultipleObjects() are not in hwloc since they have
> nothing to do with topologies."
>
> I thought hwloc was also for threading?
It can bind your threads, yes, but the way to create the thread is
yours,
Hello,
Brice Goglin, le Tue 20 Nov 2012 15:26:37 +0100, a écrit :
> I just released 1.6rc2 (mirrors will update soon).
It seems fine in my tests, can somebody test on AIX?
Samuel
Kenneth A. Lloyd, le Mon 21 Jan 2013 22:46:37 +0100, a écrit :
> Thanks for making this tutorial available. Using hwloc 1.7, how far down
> into, say, NVIDIA cards can the architecture be reflected? Global memory
> size? SMX cores? None of the above?
None of the above for now. Both are
cesse...@free.fr, le Tue 29 Jan 2013 19:12:32 +0100, a écrit :
> It was a very stupid question indeed !
Well, no it's not stupid :)
Zero-allocs can indeed be frowned upon. Some algorithms like doing it,
but some others to actually bug out at the same time allocating 0 bytes.
Samuel
Eloi Gaudry, le Mon 06 Jan 2014 16:04:27 +0100, a écrit :
> On Windows, hwloc_get_cpubind and hwloc_set_cpubind works correctly but I
> cannot use hwloc_get_proc_cpubind or hwloc_set_proc_cpubind using the current
> process handle as 2^nd parameter (no matter what the last one is).
>
> Any clue
Eloi Gaudry, le Mon 06 Jan 2014 16:37:55 +0100, a écrit :
> AFAIK, the issue seems related to the GetAffinityMask call inside
> hwloc_win_get_proc_cpubind : it always returns 0.
So it's really the win32 layer which does not like seeing
GetAffinityMask called. Just to make sure: you are using at
Eloi Gaudry, le Mon 06 Jan 2014 17:16:53 +0100, a écrit :
> the PID of the process. I was assuming that casting this member to a HANDLE
> object would allow me to use hwloc_get_proc_cpubind,
No, PIDs are mere numbers, they have nothing to do with HANDLES. More
interestingly, PID values are valid
Samuel Thibault, le Mon 06 Jan 2014 18:07:59 +0100, a écrit :
> Eloi Gaudry, le Mon 06 Jan 2014 17:16:53 +0100, a écrit :
> > the PID of the process. I was assuming that casting this member to a HANDLE
> > object would allow me to use hwloc_get_proc_cpubind,
Let me fix my t
Erik Schnetter, le Sat 18 Jan 2014 07:29:37 +0100, a écrit :
> You probably need to set CFLAGS in addition to CXXFLAGS.
Yes, CXXFLAGS is for C++ files. hwloc doesn't have any :)
It's CFLAGS which is for C.
That being said, I wonder the gain you will have: all the probing
functions will still
1 - 100 of 123 matches
Mail list logo
