On Nov 11, 2009, at 1:29 PM, Samuel Thibault wrote:
> How about HWLOC_UNSUPPORTED_SYS?
I don't think it's a good idea to make it a compile-time thing rather
than a runtime-time thing: if we expose to the application the fact
that the OS on which the application is building is not supported, it
One thing to not forget is that some (many?) applications don't care a
whit about portability to other OS's. You view feature X as a
portability horror; they view it as a feature.
Hence, they may actually *want* to take advantage of the ability to
pin a specific thread (that is not the cur
On Nov 11, 2009, at 4:22 PM, Samuel Thibault wrote:
Another way to go is in hwloc_plpa_sched_setaffinity put in
#ifdef HWLOC_LINUX_SYS some code that calls the internal
hwloc_linux_set_tid_cpubind (with a strong comment that nobody else
should call it), so that
- existing linux plpa users can h
On Nov 11, 2009, at 4:57 PM, Samuel Thibault wrote:
Maybe what we can do is using PLPA's functions if __GLIBC__ is <=
2 and __GLIBC_MINOR__ is < the first version which is known to be
correct or if CPU_SET can't be compiled, and rely on the glibc
functions else. Of course we have to rely on gli
Jeff Squyres, le Thu 12 Nov 2009 08:28:32 -0800, a écrit :
> One thing to not forget is that some (many?) applications don't care a
> whit about portability to other OS's. You view feature X as a
> portability horror; they view it as a feature.
>
> Hence, they may actually *want* to take adva
Jeff Squyres, le Thu 12 Nov 2009 08:31:50 -0800, a écrit :
> On Nov 11, 2009, at 4:22 PM, Samuel Thibault wrote:
> >- non-linux plpa users are restricted to what really is portable.
> >
>
> PLPA = Linux only. :-)
I know, but there's usually no reason why they shouldn't now target
non-Linux too.
Jeff Squyres, le Thu 12 Nov 2009 08:34:24 -0800, a écrit :
> On Nov 11, 2009, at 4:57 PM, Samuel Thibault wrote:
> >Maybe what we can do is using PLPA's functions if __GLIBC__ is <=
> >2 and __GLIBC_MINOR__ is < the first version which is known to be
> >correct or if CPU_SET can't be compiled, and
Sorry for the delay in replying to this; been caught up in SC09 prep...
On Nov 5, 2009, at 8:22 AM, Brice Goglin wrote:
* PLPA-like API is prefixed with hwloc_plpa_ and all functions get a
new
hwloc_topology_t parameter. The problematic ones are:
+ int hwloc_plpa_sched_getaffinity(pid_t pi
On Nov 12, 2009, at 8:48 AM, Samuel Thibault wrote:
> On Nov 11, 2009, at 4:57 PM, Samuel Thibault wrote:
> >Maybe what we can do is using PLPA's functions if __GLIBC__ is <=
> >2 and __GLIBC_MINOR__ is < the first version which is known to be
> >correct or if CPU_SET can't be compiled, and rely
Jeff Squyres, le Thu 12 Nov 2009 08:58:19 -0800, a écrit :
> The *only* weird possibility would be if RH (or Suse) patched their
> old glibcs to fix this problem but didn't update the minor number.
Ok but in that case we'd just use the PLPA implementation that should
work fine. On the long ru
On Nov 12, 2009, at 8:44 AM, Samuel Thibault wrote:
I'm not saying pinning a specific thread is a horror. I'm saying
expressing which thread should be bound through tids instead of
pthread_t is. The only sane way I could see an application use tids
is a monitoring application that looks into /p
On Nov 12, 2009, at 9:05 AM, Samuel Thibault wrote:
> The *only* weird possibility would be if RH (or Suse) patched their
> old glibcs to fix this problem but didn't update the minor number.
Ok but in that case we'd just use the PLPA implementation that should
work fine. On the long run RH/Suse
Jeff Squyres wrote:
>> * PLPA-like API is prefixed with hwloc_plpa_ and all functions get a new
>> hwloc_topology_t parameter. The problematic ones are:
>>
>> + int hwloc_plpa_sched_getaffinity(pid_t pid, hwloc_cpuset_t cpuset);
>>
>
> Hmm. I'm a little confused. If we don't provide a drop-in PLP
Jeff Squyres, le Thu 12 Nov 2009 09:08:45 -0800, a écrit :
> Fair enough. I think we actually agree -- these emails are quite
> confusing. :-)
Ok :)
> 1. Let's not mix thread and PIDs into a single argument like Linux does
Ok, I've just done it :)
but in the linux.h header only, for people wh
Brice Goglin, le Thu 12 Nov 2009 18:13:34 +0100, a écrit :
> Jeff Squyres wrote:
> >> * PLPA-like API is prefixed with hwloc_plpa_ and all functions get a new
> >> hwloc_topology_t parameter. The problematic ones are:
> >>
> >> + int hwloc_plpa_sched_getaffinity(pid_t pid, hwloc_cpuset_t cpuset);
>
On Nov 12, 2009, at 9:25 AM, Samuel Thibault wrote:
> > There's certainly some desirable PLPA API features that could be
> > imported to the HWLOC API -- but I would think that if people
want to
> > keep using the PLPA API, they can. It just won't [ever] be
updated.
> > The existing (and fu
Jeff Squyres wrote:
> On Nov 12, 2009, at 9:25 AM, Samuel Thibault wrote:
>
>> > > There's certainly some desirable PLPA API features that could be
>> > > imported to the HWLOC API -- but I would think that if people
>> want to
>> > > keep using the PLPA API, they can. It just won't [ever] be upda
Jeff Squyres wrote:
> Sorry for the delay in replying to this; been caught up in SC09 prep...
Next time, I'll commit immediately instead of waiting for a week in case
somebody ever reads my emails :)
Brice
On Nov 12, 2009, at 9:56 AM, Brice Goglin wrote:
Well, the list of good ideas will be very short then :) Most remaining
functions are about manipulating core and socket ids, we don't need
that
at all in hwloc anymore.
My feeling is that converting an application from PLPA's
core_id/socket_id
Jeff Squyres, le Thu 12 Nov 2009 10:05:32 -0800, a écrit :
> apps that run on specific servers for specific purposes, where the
> developers hard code in there "bind to cores 1-4" or "bind to sockets
> 1,3" because they already know the setup and this app is not intended
> to be portable.
Bu
Jeff Squyres wrote:
>> Well, the list of good ideas will be very short then :) Most remaining
>> functions are about manipulating core and socket ids, we don't need that
>> at all in hwloc anymore.
>
> FWIW, having a "simple" API like that might be a Good Thing...?
>
> I.e., just be able to bind to
FWIW, I'll be at SC09 next week, mostly on INRIA Booth #1405. I'll
present hwloc (among other software we develop here).
I'll have a USB key with lstopo static binaries (from the libpci branch)
so that people can run it on their machine immediately. I hope somebody
will show up with a 192-core lap
On Thu, 2009-11-12 at 19:47 +0100, Brice Goglin wrote:
> FWIW, I'll be at SC09 next week, mostly on INRIA Booth #1405. I'll
> present hwloc (among other software we develop here).
I'll swing round and say hi.
> I'll have a USB key with lstopo static binaries (from the libpci branch)
> so that peo
Ashley Pittman, le Thu 12 Nov 2009 19:11:11 +, a écrit :
> I just tried to run it on my arm but failed as I only have autoconf
> 2.61,
You can run ./configure && make dist on another machine to get an
autoconfied tarball ready to unpack/conf/make.
Samuel
Samuel Thibault wrote:
> Ashley Pittman, le Thu 12 Nov 2009 19:11:11 +, a écrit :
>
>> I just tried to run it on my arm but failed as I only have autoconf
>> 2.61,
>>
>
> You can run ./configure && make dist on another machine to get an
> autoconfied tarball ready to unpack/conf/make.
>
On Thu, 2009-11-12 at 20:30 +0100, Samuel Thibault wrote:
> Ashley Pittman, le Thu 12 Nov 2009 19:11:11 +, a écrit :
> > I just tried to run it on my arm but failed as I only have autoconf
> > 2.61,
>
> You can run ./configure && make dist on another machine to get an
> autoconfied tarball rea
Creating nightly hwloc snapshot SVN tarball was a success.
Snapshot: hwloc 1.0a1r1339
Start time: Thu Nov 12 21:01:02 EST 2009
End time: Thu Nov 12 21:02:54 EST 2009
Your friendly daemon,
Cyrador
27 matches
Mail list logo
