Hello,
For information, glibc is struggling with the problematic of the
precise meaning of get_nprocs, get_nprocs_conf, _SC_NPROCESSORS_CONF,
_SC_NPROCESSORS_ONLN
https://sourceware.org/pipermail/libc-alpha/2022-February/136177.html
Samuel
___
Yogesh Sharma, le sam. 18 juil. 2020 15:59:57 +0530, a ecrit:
> i am new to ubuntu. can you give me a moment and help me get through command
> lines here
It is really just the same as you tried, but with the libhwloc-dev
package instead of hwloc.
Samuel
Hello,
Yogesh Sharma, le sam. 18 juil. 2020 15:02:30 +0530, a ecrit:
> i tried sudo apt -get hwloc=1.11.3
It is the libhwloc-dev package that you need to downgrade.
But 1.11 is old, and the software really needs to be ported to the hwloc
2 API.
Samuel
Balaji, Pavan, le mar. 02 juin 2020 09:31:29 +, a ecrit:
> > On Jun 1, 2020, at 4:11 AM, Balaji, Pavan via hwloc-users
> > wrote:
> >> On Jun 1, 2020, at 4:10 AM, Balaji, Pavan wrote:
> >>> On Jun 1, 2020, at 4:06 AM, Samuel Thibault
> >>> wrot
Balaji, Pavan, le lun. 01 juin 2020 09:10:21 +, a ecrit:
> > On Jun 1, 2020, at 4:06 AM, Samuel Thibault
> > wrote:
> > could you check whether the attached patch avoids the warning?
> > (we should really not need a cast to const char*)
>
> The attached patch
Hello,
Balaji, Pavan via hwloc-users, le lun. 01 juin 2020 03:39:02 +, a ecrit:
> We are seeing some warnings with the Intel compiler with hwloc (listed
> below). The warnings seem to be somewhat silly because there already is a
> cast to "char *" from the string literal,
Well, I'd agree
Brice Goglin, on dim. 12 nov. 2017 05:19:37 +0100, wrote:
> That's likely what's happening. Each set_area() may be creating a new "virtual
> memory area". The kernel tries to merge them with neighbors if they go to the
> same NUMA node. Otherwise it creates a new VMA.
Mmmm, that sucks. Ideally
Hello,
TEJASWI k, on ven. 13 oct. 2017 14:44:53 +0530, wrote:
> Thanks I could get the linkspeed when i tried with root user.
> But is there no other way?
See Brice's answer :)
> And what is the reason behind this limitation?
Ask Linux people, not us :)
I can only guess that they are afraid
Hello,
TEJASWI k, on ven. 13 oct. 2017 14:23:00 +0530, wrote:
> All the other details I am able to query but linkspeed (pciObj->attr->
> bridge.upstream.pci.linkspeed) is always 0.
> Do I need to enable any other flag to get linkspeed or am I going wrong
> somewhere?
You need to run as root for
Hello,
The other day I modified the output of lstopo --ps to contain the end of
the cmdline instead of the beginning, because with module systems,
spack, etc. the path to application binaries get longer and longer, and
eventually the actual name of the binary goes away on the right.
But
Gilles Gouaillardet, on ven. 21 juil. 2017 10:57:36 +0900, wrote:
> if you are fine with using more memory, and your application should not
> generate too much unexpected messages, then you can bump the eager_limit
> for example
>
> mpirun --mca btl_tcp_eager_limit $((8*1024*1024+128)) ...
Hello,
George Bosilca, on jeu. 20 juil. 2017 19:05:34 -0500, wrote:
> Can you reproduce the same behavior after the first batch of messages ?
Yes, putting a loop around the whole series of communications, event
with a 1-second pause in between, gets the same behavior repeated.
> Assuming the
Hello,
We are getting a strong performance issue, which is due to a missing
pipelining behavior from OpenMPI when running over TCP. I have attached
a test case. Basically what it does is
if (myrank == 0) {
for (i = 0; i < N; i++)
MPI_Isend(...);
} else {
for (i =
Hello,
Maureen Chew, on jeu. 08 juin 2017 10:51:56 -0400, wrote:
> Should finding cache & pci info work?
AFAWK, there is no user-available way to get cache information on
Solaris, so it's not implemented in hwloc.
Concerning pci, you need libpciaccess to get PCI information.
Samuel
Hello,
Gunter, David O, on jeu. 04 mai 2017 20:44:16 +, wrote:
> launching lstopo always produces the text-based output. I cannot seem
> to get the X-display features to work. And yes, I am able to launch
> xterms and other X11-based apps correctly.
Do you have the DISPLAY environment
Hello,
Gunter, David O, on Fri 27 Jan 2017 18:05:44 +, wrote:
> $ aprun -n 1 -L 193 ~hwloc-tt/bin/lstopo-no-graphics
Does aprun give you allocation of all cores? By default lstopo only
shows the allocated cores. To see all of them, use the --whole-system
option.
Samuel
Hello,
Jacob Peter Caswell, on Mon 16 Jan 2017 11:53:56 -0600, wrote:
> x86_64-k1om-linux-ld: i386:x86-64 architecture of input file `.libs/support.o'
> is incompatible with k1om output
Did you make clean before reconfiguring+making?
Samuel
___
Hello,
Alberto Ortiz, on Mon 12 Dec 2016 18:03:23 +0100, wrote:
> These gpios are included to the PS by looking into the device tree, and
> located
> in /sys/class.
> I know hwloc is able to find PCI devices, but i would like to know if hwloc is
> able to detect other type of I/O like the ones
Brice Goglin, on Tue 26 Apr 2016 15:45:49 +0200, wrote:
> The Hardware Locality (hwloc) team is pleased to announce the release
> of v1.11.3:
I'm getting one testsuite issue:
FAIL: 16-2gr2gr2n2c+misc.xml
(gdb) bt
#0 strlen () at ../sysdeps/x86_64/strlen.S:106
#1 0x77346d8e in
Jeff Squyres (jsquyres), le Thu 11 Dec 2014 21:12:27 +, a écrit :
> When the BIOS is set to enable hyper threading, then several resources on the
> core are split when the machine is booted up (e.g., some of the queue depths
> for various processing units in the core are half the length that
Vishwanath Venkatesan, le Mon 29 Sep 2014 13:38:35 -0700, a écrit :
> I was trying to use HWLOC on Ivybridge. I found that there is some
> inconsistency in the core numbering.
>
> In the attached image (generated from running lstopo (hwloc - 1.9.1), we can
> see that cores 6,7 do not exist
Dennis Jacobfeuerborn, le Thu 25 Sep 2014 02:01:48 +0200, a écrit :
> The question I guess is how does the command determine the availability
> of png as an output? Both cairo and libpng are installed.
It depends on the backends which were built into cairo.
Samuel
Biddiscombe, John A., le Tue 25 Mar 2014 08:56:02 +, a écrit :
> Looking at /proc/cpuinfo on the io node itself, I see only 60 cores listed. I
> wonder if they’ve reserved one socket of 4 cores for IO purposes
That's possible, yes.
> and in fact hwloc is seeing the correct information.
At
Brice Goglin, le Thu 13 Feb 2014 23:18:04 +0100, a écrit :
> IIRC, Windows warnings are function pointer casts that should be OK.
IIRC too.
Samuel
Brock Palen, le Thu 06 Feb 2014 21:31:42 +0100, a écrit :
> GPU L#3 "nvml2"
> GPU L#5 "nvml3"
> GPU L#7 "nvml0"
> GPU L#9 "nvml1"
>
> Is the L# always going to be in the oder I would expect? Because then I
> already have my map then.
No,
Brice Goglin, le Tue 28 Jan 2014 12:46:24 +0100, a écrit :
> 42: xchg %ebx,%rbx
>
> I guess having both ebx and rbx on these lines isn't OK. On Linux, I get
> rsi instead of ebx, no problem.
>
> Samuel, any idea?
Mmm, IIRC, "unsigned long" on windows may not be 64bit but 32bit?
Perhaps we
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
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
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
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 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
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
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
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
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,
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],
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 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
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
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
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.
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
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
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
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
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:
>
> -
>
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 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
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 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
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
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
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
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
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);
> > >>> +
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
>
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,
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
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
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
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.
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
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 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
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 :
> 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
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
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
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
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
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
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
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 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);
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 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
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 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
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 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 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 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 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 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 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 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
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 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);
>
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 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?
>
>
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 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
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 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 =
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
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
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 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,
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
> >
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,
1 - 100 of 126 matches
Mail list logo
