Brice,
thanks for looking into it!
Regarding the naming. I would argue that since the utility is currently
called
hwloc-gather-topology.sh
then the man page should be named
hwloc-gather-topology.sh.1
What's your opinion?
I have just one question regarding this code:
if [ -z "$name" -o x`echo $n
Le 20/12/2010 20:06, Guy Streeter a écrit :
> I decided I should just give you the whole output.
Thanks. Indeed, it's a Linux "feature". When you request a non-strict
memory binding in Linux (MPOL_PREFERRED, not MPOL_BIND), it only keeps
the first node in the input nodemask. Instead of allocating
On 12/20/2010 12:56 PM, Brice Goglin wrote:
Le 20/12/2010 19:40, Guy Streeter a écrit :
Get this singlethreaded process memory : expected 0x000f, got
0xf...f
Is that a bug?
That's on my Fedora 13 non-numa system.
This is kind of expected. 0x000f means all the cores in the machine.
0x
On 12/20/2010 12:56 PM, Brice Goglin wrote:
Le 20/12/2010 19:40, Guy Streeter a écrit :
Get this singlethreaded process memory : expected 0x000f, got
0xf...f
Is that a bug?
That's on my Fedora 13 non-numa system.
This is kind of expected. 0x000f means all the cores in the machine.
0x
Le 20/12/2010 19:40, Guy Streeter a écrit :
> Get this singlethreaded process memory : expected 0x000f, got
> 0xf...f
>
> Is that a bug?
> That's on my Fedora 13 non-numa system.
This is kind of expected. 0x000f means all the cores in the machine.
0xf...f means all the machine when the ma
On 12/16/2010 06:03 AM, Jeff Squyres wrote:
Both have been posted.
http://www.open-mpi.org/software/hwloc/v1.0/
http://www.open-mpi.org/software/hwloc/v1.1/
I have not updated the docs for these rc's on the web site in anticipation that
these are final/quick rc's and the real release
Le 20/12/2010 15:20, Bernd Kallies a écrit :
> Hallo,
>
> while browsing through the implementation of the bitmap API in hwloc 1.1
> and comparing it with the cpuset API of hwloc 1.0, it turns out that
> hwloc_bitmap_alloc uses malloc and leaves struct member ulongs
> uninitialized, wheres 1.0 used
Hallo,
while browsing through the implementation of the bitmap API in hwloc 1.1
and comparing it with the cpuset API of hwloc 1.0, it turns out that
hwloc_bitmap_alloc uses malloc and leaves struct member ulongs
uninitialized, wheres 1.0 used calloc.
This leads to random bitmap content after crea
Jirka,
I have committed (locally) some changes that should address everything
you reported and that are ok to backport in 1.1. I improved your manpage
proposal too. See attached. By the way, I don't know if the manpage
should be named .1 or .sh.1.
There won't be any 1.1.1 release before a couple we
Le 19/12/2010 23:30, Jiri Hladky a écrit :
> In the current version (1.1), hwloc-gather-topology.sh is not very robust:
hwloc-gather-topo already changed in trunk since the 1.1 release
unfortunately, I need to see if your changes still apply. Apart from
that, it should be ok for trunk.
However I
10 matches
Mail list logo
