On Jul 24, 2009, at 1:51 AM, Chris Samuel wrote:
> I'm still on leave at present, so you've not seen me,
> right ? :-)
>
Seen who? :-)
> FWIW Torque does not use libcpuset as SGI didn't release
> the code to the version to cope with the 2.6 kernel until
> later (despite prodding), it directly manipulates the
> contents of /dev/cpuset instead.
>
> PLPA should be able to learn the cores available to it though
> as plpa-taskset returns the correct information for processes
> in a cpuset.
>
Since PLPA has no decision-making capabilities (i.e., it only does
exactly what you tell it to do), I think that this may be sufficient
-- PLPA's existing interfaces already allow you to discover the IDs
that you're bound to. It's up to the caller to determine how to use
those appropriately.
Is there any way for a process to tell the difference between "I can
bind to completely different processors than I'm already bound
to" (i.e., someone just happened to bind me to cores X, Y, and Z, but
I'm free to bind to cores A, B, and C if I want to) and "I can only
bind to cores within the set that I'm already bound to" (i.e., cpuset)?
Perhaps PLPA should be able to report:
- here's the processors PID X is bound to
- here's the processors in PID X's cpuset
Then the caller can decide what to do rationally and not be surprised
if they get an -EVINVAL because they've chosen processors that are
outside of their cpuset.
Admittedly, I have not looked at libcpuset yet -- is this something
that libcpuset does? If so, we could get that kind of functionality
by linking into libcpuset (if it's available).
The reason that I suggest this is that (I *assume* that) rather than
have callers have to link to both PLPA and libcpuset manually and
attempt to merge the data between the two different data structures,
there *may* be some value (i.e., simplicity) in having a single
interface and set of data structures that can address both issues.
Thoughts?
--
Jeff Squyres
jsquyres_at_[hidden]
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}