On Jan 30, 2007, at 5:44 AM, David Creasy wrote:
> Thanks very much indeed for the speedy responses Paul and Jeff - that
> fixes the problem.
Excellent.
> I've a slightly unrelated question about the return from
> plpa_sched_getaffinity. It seems that on a dual core, dual cpu AMD
> system, with SuSE 10.0, all the bits are set. (I don't have such a
> system here, this is a report from one of our customers). I don't see
> this on other systems, and I don't understand the line in the man page
> for sched_setaffinity that says: "Usually, all bits in the mask are
> set".
> Trying to set the affinity to an invalid processor on this system with
> plpa_sched_setaffinity fails, so I can determine which processors are
> present that way - it just seems a bit strange...
I assume you're referring to this specific language:
-----
The affinity mask is represented by the bitmask stored in
mask. The
least significant bit corresponds to the first logical
processor num-
ber on the system, while the most significant bit
corresponds to the
last logical processor number on the system. A set bit
corresponds to
a legally schedulable CPU while an unset bit corresponds to
an ille-
gally schedulable CPU. In other words, a process is bound to
and will
only run on processors whose corresponding bit is set.
Usually, all
bits in the mask are set.
-----
Perhaps the wording is somewhat confusing -- they're distinguishing
between "legally schedulable CPUs" and physically-existing CPUs (or
cores). In order words, if you set bit 13, you're eligible to run on
processor 13 regardless of whether it exists in the system or not.
Put simply: the linux kernel will ignore the bits for processors that
don't exist. So you can set those values to whatever you want. For
example, setting the mask to ((appropriate_size_t) ~0) will
effectively disable affinity, regardless of how many processors you
have.
--
Jeff Squyres
Server Virtualization Business Unit
Cisco Systems
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}