Re: [hwloc-devel] Change bind API.

2010-03-22 Thread Samuel Thibault 
Bert Wesarg, le Sun 21 Mar 2010 13:31:14 +0100, a écrit :
> I would like to propose an interface change for these function, so
> that the caller provide the to-be-filled cpuset, to reduce the
> alloc/free frequency.

This is indeed better (and actually reduces the amount of code in
hwloc), I have implemented it.

Samuel

Re: [hwloc-devel] Change bind API.

2010-03-22 Thread Bert Wesarg 
On Mon, Mar 22, 2010 at 11:21, Samuel Thibault  wrote:
> Bert Wesarg, le Sun 21 Mar 2010 13:31:14 +0100, a écrit :
>> I would like to propose an interface change for these function, so
>> that the caller provide the to-be-filled cpuset, to reduce the
>> alloc/free frequency.
>
> This is indeed better (and actually reduces the amount of code in
> hwloc), I have implemented it.

Thanks a lot.

Bert

>
> Samuel
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r1840

2010-03-22 Thread Samuel Thibault 
Bert Wesarg, le Mon 22 Mar 2010 12:20:58 +0100, a écrit :
> > -static hwloc_cpuset_t
> > -hwloc_aix_get_thisproc_cpubind(hwloc_topology_t topology, int policy)
> > +static int
> > +hwloc_aix_get_thisproc_cpubind(hwloc_topology_t topology, hwloc_cpuset_t 
> > hwloc_set, int policy)
> >  {
> >   rsid_t who = { .at_pid = getpid() };
> 
> This one came to my intention while looking over the commit, but
> shouldn't this be topology->pid as of r1837?

It could, but it should not (yet).  setpid is supposed to change the
behavior of all functions, not just cpu bindings.  For now, this is only
supported on Linux, other OSes will return ENOSYS.  I do not know how
to make the AIX backend use the personality of another process for the
topology detection, that is why setpid is not (yet) enabled on it.

Samuel

Re: [hwloc-devel] 1.0-rc1

2010-03-22 Thread Bert Wesarg 
On Mon, Mar 22, 2010 at 21:29, Brice Goglin  wrote:
> Brice Goglin wrote:
>> Are we doing a 1.0-rc1 soon ?
>>
>
> Same question again :)

I suspect, I can't propose API changes after that, right? ;-)

Bert

>
> Brice
>

Re: [hwloc-devel] 1.0-rc1

2010-03-22 Thread Jeff Squyres 
On Mar 22, 2010, at 4:34 PM, Bert Wesarg wrote:

> > Same question again :)
> 
> I suspect, I can't propose API changes after that, right? ;-)

It would be good, yes.  :-)

Have you had a good look around hwloc?  I.e., do you have a feel for whether 
you will be suggesting any more API changes?

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] 1.0-rc1

2010-03-22 Thread Bert Wesarg 
On Mon, Mar 22, 2010 at 21:49, Jeff Squyres  wrote:
> On Mar 22, 2010, at 4:34 PM, Bert Wesarg wrote:
>
>> > Same question again :)
>>
>> I suspect, I can't propose API changes after that, right? ;-)
>
> It would be good, yes.  :-)
>
> Have you had a good look around hwloc?  I.e., do you have a feel for whether 
> you will be suggesting any more API changes?

Only a cursory one and mostly inside the linux backend. Here are some
thoughts: Thats more a personal favor, but anyway: In case of the
binary cpuset operations I find the ' =  op ' style
more flexible, than the current ' op= ' style. I would
also rename hwloc_cpuset_clearset() to hwloc_cpuset_andnotset(), so it
fits to the _{or,and,xor,not}set naming style (i.e. they are named
after the bit operation).

I myself don't expect any API changes from me anymore.

Bert