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

2009-11-12 Thread Samuel Thibault
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

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

2009-11-12 Thread Jeff Squyres
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

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

2009-11-12 Thread Samuel Thibault
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.

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

2009-11-12 Thread Samuel Thibault
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

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

2009-11-12 Thread Jeff Squyres
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

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

2009-11-12 Thread Jeff Squyres
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

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

2009-11-11 Thread Samuel Thibault
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 have the same behavior, but we can document here that

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

2009-11-11 Thread Samuel Thibault
Brice Goglin, le Thu 12 Nov 2009 00:31:48 +0100, a écrit : > The problem is that our hwloc/Linux does not implement > set_proc_cpubind() so far. But it can implement one that assumes that the target process is singlethreaded, i.e. in hwloc_set_proc_cpubind distinguish between

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

2009-11-11 Thread Brice Goglin
Samuel Thibault wrote: > bgog...@osl.iu.edu, le Wed 11 Nov 2009 11:33:31 -0500, a écrit : > >> +/** \brief Bind thread given by \p pid to CPU set \p cpuset. >> + * >> + * \note This function now manipulates hwloc cpusets. >> + */ >> +static __inline int >>

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

2009-11-11 Thread Samuel Thibault
bgog...@osl.iu.edu, le Wed 11 Nov 2009 11:33:31 -0500, a écrit : > +/** \brief Bind thread given by \p pid to CPU set \p cpuset. > + * > + * \note This function now manipulates hwloc cpusets. > + */ > +static __inline int > +hwloc_plpa_sched_setaffinity(hwloc_topology_t topology, hwloc_pid_t pid,

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

2009-11-11 Thread Samuel Thibault
bgog...@osl.iu.edu, le Wed 11 Nov 2009 11:33:31 -0500, a écrit : > + /* FIXME: should be SET_THREAD_CPUBIND given with a pid */ > + if (flags & HWLOC_SUPPORT_SET_PROC_CPUBIND) > +*api_type = HWLOC_PLPA_PROBE_OK; > + else > +*api_type = HWLOC_PLPA_PROBE_NOT_SUPPORTED; > + return 0; > +}