Le 12/09/2011 21:13, Jeff Squyres a écrit :
> I had a thought about this issue this morning:
>
> 1. The XML export without libxml2 should be pretty easy (right?).
I didn't try it but yes it should.
> 2. If we're importing exactly what was exported, that should also be pretty
> easy without libxm
I had a thought about this issue this morning:
1. The XML export without libxml2 should be pretty easy (right?).
2. If we're importing exactly what was exported, that should also be pretty
easy without libxml2 (right?). Meaning: there can be a very simplistic parser
that only handles the expec
Le 06/09/2011 17:39, Jeff Squyres a écrit :
> On Sep 6, 2011, at 11:25 AM, Brice Goglin wrote:
>
>>> - I don't know where we ended up in the other thread: do we want JSON or
>>> no? If we can parse it easily without an external dependency, then I think
>>> it's worthwhile.
>> I stopped working o
On Sep 6, 2011, at 11:25 AM, Brice Goglin wrote:
>> - I don't know where we ended up in the other thread: do we want JSON or no?
>> If we can parse it easily without an external dependency, then I think it's
>> worthwhile.
>
> I stopped working on JSON this to see where the idea of reimplement
Le 06/09/2011 16:53, Jeff Squyres a écrit :
> On Sep 6, 2011, at 10:44 AM, Brice Goglin wrote:
>
>> v1.3rc1 has been released two weeks ago and many things are going on
>> right now, in all branches:
>> * I just finished fixing my pile of distance-related bugs (thanks to
>> multinode support and OM
On Sep 6, 2011, at 10:44 AM, Brice Goglin wrote:
> v1.3rc1 has been released two weeks ago and many things are going on
> right now, in all branches:
> * I just finished fixing my pile of distance-related bugs (thanks to
> multinode support and OMPI users). I backported the really important
> ones
v1.3rc1 has been released two weeks ago and many things are going on
right now, in all branches:
* I just finished fixing my pile of distance-related bugs (thanks to
multinode support and OMPI users). I backported the really important
ones in v1.3 and v1.2. Do we want a 1.2.2?
* I applied some non-
It's been 3 weeks since we discussed the membind interface. How far are
we from an acceptable API? Is there anything missing apart from
documentation updates? Should I revert the cpumembind stuff?
I'd like some feedback about the distance API too. The internal
implementation isn't perfect yet, but
On Sep 28, 2010, at 6:41 PM, Brice Goglin wrote:
> Jeff, can you check on your Mac that lstopo from 1.0 works with libhwloc
> from the latest bitmap branch?
I had to fake out the VERSION information, but after doing that, it works. So
I think we're good.
--
Jeff Squyres
jsquy...@cisco.com
For
Le 28/09/2010 11:29, Samuel Thibault a écrit :
> Brice Goglin, le Fri 24 Sep 2010 13:31:06 +0200, a écrit :
>
>> By the way, what's the proper way to do the latter?
>> #pragma weak hwloc_cpuset_foo = hwloc_bitmap_foo ?
>> use __hwloc_attribute_alias instead ?
>>
> There is no proper way unf
Brice Goglin, le Fri 24 Sep 2010 13:31:06 +0200, a écrit :
> By the way, what's the proper way to do the latter?
> #pragma weak hwloc_cpuset_foo = hwloc_bitmap_foo ?
> use __hwloc_attribute_alias instead ?
There is no proper way unfortunately: the Mach-O format used by MacOS
does not support such
The bitmap branch looks good to me. There might still be some
documentation/comments to update, but nothing big. Given how intrusive
this branch is, I'd rather merge it early instead of fixing conflicts in
other branches for a long time :)
What I need first is somebody to check my pragma at the en
Sounds good.
On Sep 24, 2010, at 7:30 AM, Brice Goglin wrote:
> Here's a proposal for the new renamed cpuset API. Non trivial changes
> include:
> hwloc_cpuset_from_string -> hwloc_bitmap_sscanf
> hwloc_cpuset_cpu -> hwloc_bitmap_setonly
> hwloc_bitmap_all_but_cpu -> hwloc_bitmap_allbut
>
> My p
Here's a proposal for the new renamed cpuset API. Non trivial changes
include:
hwloc_cpuset_from_string -> hwloc_bitmap_sscanf
hwloc_cpuset_cpu -> hwloc_bitmap_setonly
hwloc_bitmap_all_but_cpu -> hwloc_bitmap_allbut
My plan would be to:
* commit the attached file as hwloc/bitmap.h
* drop everythin
Jeff Squyres, le Wed 22 Sep 2010 13:37:12 +0200, a écrit :
> I think we should support memory binding, even if it does weird things --
> i.e., dropping membinding support on a given OS shouldn't be an option.
That's why I'd tend to keep set_cpubind and set_membind, warning that
one may have impac
Please people on the list tell us what your needs are, else we can't for
sure design things a proper way!
Brice Goglin, le Wed 22 Sep 2010 14:13:20 +0200, a écrit :
> Le 22/09/2010 13:36, Jeff Squyres a écrit :
> > On Sep 22, 2010, at 4:38 AM, Brice Goglin wrote:
> >> There are still some problems
Le 22/09/2010 16:30, Jeff Squyres a écrit :
> On Sep 22, 2010, at 8:09 AM, Brice Goglin wrote:
>
>
>> hwloc_set_*? hwloc_objset* ? Anything better?
>>
>> hwloc_set_* might not be the best since we would have a hwloc_set_set()
>> function to set one bit :)
>>
> Agreed. Too bad, though -- I
On Sep 22, 2010, at 8:09 AM, Brice Goglin wrote:
> hwloc_set_*? hwloc_objset* ? Anything better?
>
> hwloc_set_* might not be the best since we would have a hwloc_set_set()
> function to set one bit :)
Agreed. Too bad, though -- I liked hwloc_set*.
hwloc_group* (that seems kinda lame, though)
Brice Goglin, le Wed 22 Sep 2010 10:38:38 +0200, a écrit :
> * Some OS bind the process too when you bind memory.
Not for all kinds of memory bindings. For now, nothing that has been
commited does that, it's only the remaining TODOs. The bindings in
question are policy binding, i.e. not binding so
Le 22/09/2010 13:36, Jeff Squyres a écrit :
> On Sep 22, 2010, at 4:38 AM, Brice Goglin wrote:
>
>
>> There are still some problems to solve in the membind branch:
>> * Some OS bind the process too when you bind memory. I see the following
>> solutions:
>> + Add a flag such as HWLOC_MEMBIND_EVE
On Sep 22, 2010, at 4:38 AM, Brice Goglin wrote:
> There are still some problems to solve in the membind branch:
> * Some OS bind the process too when you bind memory. I see the following
> solutions:
> + Add a flag such as HWLOC_MEMBIND_EVEN_IF_FAR_FROM_PROCESS so that
> the user can explicitly
Hello,
hwloc 1.0 was released in May. I think we should release 1.1 before
SC10, which means doing a first RC within a couple weeks.
trunk got many changes since 1.0, but nothing very important. trac says
we're missing memory binding, distances and user-defined process
restrictions. Memory bindin
22 matches
Mail list logo
