Hello,
Marco Atzeri, le dim. 26 janv. 2025 21:36:05 +0100, a ecrit:
> https://www.open-mpi.org/software/hwloc/v2.10/downloads/hwloc-2.11.2.tar.bz2
There is a mismatch between 2.10 and 2.11.2?
Samuel
To unsubscribe from this group and stop receiving emails from it, send an email
to hwloc-users+
Hello,
Thompson, Matt (GSFC-610.1)[SCIENCE SYSTEMS AND APPLICATIONS INC] via
hwloc-users, le mar. 25 juin 2024 19:24:24 +, a ecrit:
> But when I ran lstopo, the resulting SVG sort of has all the cores "smooshed"
> so you see core 0, core 1, ... core 71.
>
> Is there an lstopo option that wi
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
___
hwloc-us
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 w
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 we'
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 of
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 h
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 conversel
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 variabl
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 Tue 17 Jan 2017 11:43:07 -0600, wrote:
> However, I'm still getting some make issues. After running make, I'm getting
> the following output:
>
> x86_64-k1om-linux-ld: warning: libimf.so, needed by /home/caswell/hwloc/hwloc
> /.libs/libhwloc.so, not found (try using
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
___
hwloc-u
Xavier LACOSTE, on Thu 05 Jan 2017 13:25:56 +, wrote:
> It seems that the __GNU__ is defined so I don’t get into the HWLOC_HAVE_FFSL
> section.
Do you mean __GNUC__? And which value does it have?
In other words: what, exactly, actually gets included from that file?
:)
Samuel
___
Xavier LACOSTE, on Thu 05 Jan 2017 11:31:23 +, wrote:
> Hwloc builds correctly with gcc compiler but the CPUVendor field is not
> available using this code :
The code looks right and works here. What output do you get? Could you
post the output of
lstopo test.xml
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 i
Hello,
Brice Goglin, on Tue 25 Oct 2016 10:56:30 +0200, wrote:
> It's not running as an
> APK, but it's running inside a shell that was launched by an APK
> (sshdroid, a ssh server shell). Not sure why this would be different?
IIRC such shells have to circumvent some OS protections to run. So the
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 __GI___st
Andrej Prsa, on Fri 30 Oct 2015 13:35:39 -0400, wrote:
> Thanks for the suggestion. I tried:
>
> mpirun --prefix /opt/openmpi-1.10.0 --hostfile node1 -np 44 sh -c
> "/usr/bin/env HWLOC_XMLFILE=/etc/hwloc_\${hostname}.xml python
> testmpi.py"
>
> and:
>
> mpirun --prefix /opt/openmpi-1.10.0 --hos
Andrej Prsa, on Fri 30 Oct 2015 09:17:32 -0400, wrote:
> > Can you have a startup script set
> > HWLOC_XMLFILE=/common/path/${hostname}.xml in the system-wide
> > environment?
>
> That's precisely what I'd been trying, but it proved exceedingly
> difficult to figure out what environment file is re
Hello,
Fabian Wein, le Tue 27 Oct 2015 09:43:22 +0100, a écrit :
> Is there a way to configure the topology manually?
Yes, you can export the current topology to an xml file:
lstopo platform.xml
then modify the platform, then use
export HWLOC_XMLFILE=platform.xml
to force using the modified x
Peyton, Jonathan L, le Fri 03 Apr 2015 21:35:23 +, a écrit :
> I was curious what the preferred environment for building hwloc on Microsoft
> Windows was. I would like to build a version that does not rely on any
> libraries except the Microsoft C library and Kernel.dll’s.
mingw should be doi
Hello,
Samy CHBINOU, le Thu 12 Mar 2015 16:37:43 +0100, a écrit :
> Is there any special options to print full informations on my processor AMD
> A10-7850K Radeon R7 12 Compute Cores 4C+8G @ 3.70GHz
> This APU has 4 CPU + 8 GPU but I can only see infos about the 4 CPU... (see
Did you make sure th
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:59:44 -0700, a écrit :
> Thanks for the quick response, yes lstopo -l does make the numbers contiguous.
> Another question I had was, how does hwloc populate the information that
> certain cpus share a particular cache?
> is it form sys/.../cache/index*/
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 althoug
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
Dennis Jacobfeuerborn, le Thu 25 Sep 2014 01:31:21 +0200, a écrit :
> I'm not sure why it would draw to an x11 window?
Well, that's what we would call a "graphical output" :)
So I guess you are saying that making a .png or .pdf doesn't work? Does
hwloc-ls --help list them as supported output for
Hello,
Pedaballe, Vineet, le Thu 28 Aug 2014 23:22:32 +, a écrit :
> I am not able to figure out how to read Hard drive details, for e.g.,
> the content provided by hdparm application.
>
> My first question is, is it possible to read this using hwloc? If yes, can
> anyone direct me to the doc
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 le
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 coul
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 get
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 typos
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 l
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 on
Eugene Loh, le Wed 06 Feb 2013 07:50:02 +0100, a écrit :
> How about adding a check upon entry to hwloc_solaris_get_sth_cpubind(): if
> processor_bind() shows binding, report this and be done. If not, then
> continue on with the lgroup logic that's already in that function. Yes?
If processor_bi
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
cesse...@free.fr, le Tue 29 Jan 2013 17:47:23 +0100, a écrit :
> ElectricFence Aborting: Allocating 0 bytes, probably a bug.
This is an old debate :)
It is not a bug, and is allowed by posix :)
You can set the environment variable
export EF_ALLOW_MALLOC_0=1
To allow malloc(0).
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 availabl
Ashley Reid, le Tue 08 Jan 2013 16:53:20 +0100, a écrit :
> Does anyone know if this is possible with OS APIs?
I don't know.
> It looks like this is not supported on Windows yet by hwloc
Indeed. I hadn't found when I had a look some years ago, I don't know if
there is something available nowaday
Erik Schnetter, le Sat 05 Jan 2013 03:58:45 +0100, a écrit :
> No, in this case I am not building with --static, and I am not passing
> --static
> to pkg-config either. However, there may be systems where I don't know whether
> the compiler (behind my back) uses --static, e.g. Cray or Blue Gene sy
Hello,
Rolf vandeVaart, le Thu 03 Jan 2013 22:30:58 +0100, a écrit :
> And config.h is specific to how the library was configured.
Not very much actually.
> Is there a special hwloc.h and supporting headers that is system independent
> so
> I can include them and build on both windows and linux
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
Samuel Thibault, le Tue 20 Nov 2012 17:58:45 +0100, a écrit :
> Andrew Somorjai, le Tue 20 Nov 2012 09:45:12 +0100, a écrit :
> > I'm also confused about these two lines and whether its necessary for the
> > second one to exist?
> >
> > HANDLE
Andrew Somorjai, le Tue 20 Nov 2012 09:45:12 +0100, a écrit :
> I'm also confused about these two lines and whether its necessary for the
> second one to exist?
>
> HANDLE thread[num_threads];
> HANDLE pthread_getw32threadhandle_np(thread);
>
> Does the second api call fill the thread array or
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, it
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:
Assertion
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 oc
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 kn
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.
Sa
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 single
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
Sebastian Kuzminsky, le Wed 03 Oct 2012 00:35:48 +0200, a écrit :
> [root@host-183 /home/nfshome/seb/tmp/hwloc-svn]# ./bin/lstopo
>
>
> * CPU cpusets *
>
> cpu 0 (os 0) has cpuset 0x0001
...
> cpu 31 (os 31) has cpuset 0x8000
> Machine#0(local=0KB total=33493800KB Backend=x86 Backend=Fr
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,
2012/9/6 Brice Goglin
>
> Anyway, having 65000 mempolicies in use is a lot. And that would somehow
> correspond to the number of set_area_membind that succeeed before one
> fails. So the kernel might indeed fail to merge those.
>
> That said, these objects are small (24by
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:
>
> -
> hwloc-b
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
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:26:50 +0200, a écrit :
> On Sep 12, 2012, at 10:30 AM, Samuel Thibault wrote:
>
> >> Sidenote: if hwloc-bind fails to bind, should we still launch the child
> >> process?
> >
> > Well, it's up to you to decide :)
Ah
Jeff Squyres, le Thu 13 Sep 2012 00:25:24 +0200, a écrit :
> On Sep 12, 2012, at 10:28 AM, Samuel Thibault wrote:
>
> >> He seems to get an hwloc error any time he tries to bind to more than 1
> >> PU. Is that expected on Solaris?
> >
> > Without
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 lgrp
Samuel Thibault, le Thu 06 Sep 2012 10:45:45 +0200, a écrit :
> Gabriele Fatigati, le Thu 06 Sep 2012 10:12:38 +0200, a écrit :
> > mbind hwloc_linux_set_area_membind() fails:
> >
> > Error from HWLOC mbind: Cannot allocate memory
>
> Ok. mbind is not really suppo
Gabriele Fatigati, le Thu 06 Sep 2012 10:12:38 +0200, a écrit :
> mbind hwloc_linux_set_area_membind() fails:
>
> Error from HWLOC mbind: Cannot allocate memory
Ok. mbind is not really supposed to allocate much memory, but it still
does allocate some, to record the policy
> //hwloc_obj
Gabriele Fatigati, le Wed 29 Aug 2012 16:56:30 +0200, a écrit :
> The id showed in the GPU box from lstopo, is the same device_id CUDA
> numeration
> used in some function like setDevice() for example?
Exactly.
Samuel
Gabriele Fatigati, le Tue 28 Aug 2012 18:10:41 +0200, a écrit :
> How can cuda branch help me? lstopo output of that branch is the same of the
> trunk.
You need to make sure that hwloc found the cuda runtime during
./configure. You will then get new "cuda" devices.
> Another question: the GPU IDs
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 cas
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 "connec
Gabriele Fatigati, le Tue 28 Aug 2012 14:19:44 +0200, a écrit :
> I attach the figure. The system has two GPUs, but I don't understand how to
> find that information from PCI boxes.
The 10de: devices are the GPUs (or alternatively, use the cuda
branch from the svn repository). The figure show
Vlad, le Thu 31 May 2012 18:07:43 +0200, a écrit :
> Thanks a lot ! This is exactly the kind of clarification I've been looking for
> and it's great to know it's been added to the official docs.
It's always better to answer a question by putting yet more doc :)
Samuel
Hello,
Vlad, le Thu 31 May 2012 16:49:00 +0200, a écrit :
> This might be a naive question, but I'd like to clarify nonetheless: to
> provide
> any sort of affinity guarantees, hwloc mem binding APIs assume that any memory
> allocation is done exclusively via hwloc_alloc_membind() and friends? A
Hello,
John Hanks, le Wed 30 May 2012 17:03:47 +0200, a écrit :
> * Hwloc has encountered what looks like an error from the operating system.
> *
> * object intersection without inclusion!
> * Error occurred in topology.c line 594
There is indeed something odd with what the Linux kernel reports:
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), &sb) == 0)
> 435max_tids = sb.st_nlink;
>
> "taskdir" here is /proc//task, correct? In which case the threads will be
> doing read
Petros Aristidou, le Thu 19 Apr 2012 13:52:05 +0200, a écrit :
> What's the truth? Is lstopo wrongly reporting that?
Lstopo simply believes what the kernel says. Please check the files
/sys/devices/system/cpu/*/cache/index2/shared_cpu_list
I guess they show just one core. The issue has to be re
Hartmut Kaiser, le Thu 15 Mar 2012 12:35:07 +0100, a écrit :
> > > Is the 32bit-on-64bit build fixed too?
>
> That does not work (see attached), but this could be a Windows problem - see
> here:
> http://msdn.microsoft.com/en-us/library/windows/desktop/dd405488(v=vs.85).as
> px, there is lengthy r
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
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
> functionnally-identical to what Samuel sent earlier.
Is the 32bit-on-64bit build fixed too?
Samuel
Samuel Thibault, le Wed 14 Mar 2012 18:16:37 +0100, a écrit :
> 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 :
> > > >>> -
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);
> > >>> + hwlo
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
> g
Hartmut Kaiser, le Tue 13 Mar 2012 17:04:53 +0100, 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, HAVE_STRINGS_H to wrap
> > > non-standard headers, un
Brice Goglin, le Tue 13 Mar 2012 20:09:57 +0100, a écrit :
> Thanks. The remaining problems don't look obvious. Something strange
> seems to happen right after the windows backend added all objects. I
> wonder if we have some problems in the bitmap management code. Can you
> try to run some tests ?
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, HAVE_STRIN
Hartmut Kaiser, le Tue 13 Mar 2012 17:38:07 +0100, a écrit :
> > Or is this a compiler-specific issue?
> > (i.e., mingw doesn't have these kinds of issues -- only MSVC does?)
>
> It's because on 64bit systems KAFFINITY has a different size than on 32 bit
> systems.
Ah, that however was probably s
Jeffrey Squyres, le Tue 13 Mar 2012 17:23:02 +0100, a écrit :
> Is the implication here that some flavors of windows have 32 bit ulongs?
win32/64 is a platform where ulong is always 32bit.
> And we need to deal with that? Or is this a compiler-specific issue? (i.e.,
> mingw doesn't have these
Brice Goglin, le Tue 13 Mar 2012 17:10:45 +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, HAVE_STRIN
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 really
Hartmut Kaiser, le Tue 13 Mar 2012 12:46:05 +0100, a écrit :
> Trying to use hwloc on a 48 bit core machine (Windows x64) causes problems,
> though. Any information requests for processing units above number 32 return
> garbage (see also the attached output of 'lstopo -of txt').
Ok, so it didn't
Marwan Abd Ellah, le Tue 13 Mar 2012 11:33:18 +0100, a écrit :
> I was using the HWLoc library v 1.4.1 for getting a cpuset of the socket
> connected to a certain PCI device (mainly GPU). When I was trying to print the
> topology tree I got the following
> Machine#0(12GB)
> Socket#0
> L3(12M
Hartmut Kaiser, le Mon 12 Mar 2012 23:05:44 +0100, a écrit :
> The library internally refers to libhwloc-4.dll (instead of
> libhwloc-5.dll).
Argl, wrong parsing indeed. Fortunately it only affects the .lib file
and not the library itself.
Samuel
1 - 100 of 274 matches
Mail list logo
