On Fri, 24 Jul 2009, Jeff Squyres wrote:
> Right. But the problem is that at least some subset of MPI users today use
> taskset/plpa_taskset to bind their MPI processes because many launchers do
> *not* already bind for them.
I must miss something. If the launcher did *not* do the binding, then
their affinity mask is full, right? So getting affinity shouldn't change
anything. If they use taskset or PLPA taskset, then they know what they're
doing, hence Open MPI shouldn't do anything ...
> But keep in mind that PLPA is wider scope than just MPI. :-)
For tools, maybe we could have an option (and actually for MPI too) like
--force to enable PLPA to get "out" of the current affinity - or on the
contrary a --stay-in-current one to tell PLPA to take the current affinity
into account.
> I guess my point is that there really are 2 different pieces of information:
>
> - what processors you *can* bind to
> - what processors you *are* bound to
I understand that, but this difference is only a difference of "rights" in
the kernel. One of the reason why we did cpusets in the kernel (as opposed
to a userland library using affinity) was that affinity was not preventing
broken programs to use cpus they were not entitled to. However, that's
just for broken programs. If a process affinity has been restricted, this
means that some component did an explicit action to restrict the affinity,
and it should (I think) be taken into account by default. Having the
possibility to try to escape may be useful as a workaround, but shouldn't
be the default case.
I mean, when I launch taskset -c 0 ./myprog, I don't want myprog to go
elsewhere, otherwise I wouldn't have used taskset, right ?
> Even if these two pieces of information are sometimes the same, sometimes
> they're not. Hence, I'm suggesting that PLPA should differentiate between
> these two when reporting information upward.
To sum up my opinion, I think these two pieces of information _should_ be
the same. If they're not, one component's action is being overriden by
some other and this should be noted/warned/forced/...
Sylvain
|