svn commit: r221614 - projects/largeSMP/sys/powerpc/include

[Attilio Rao]

2011/5/13 Bruce Evans <brde at optusnet.com.au>:
> On Thu, 12 May 2011, Attilio Rao wrote:
>
>> 2011/5/12 Artem Belevich <art at freebsd.org>:
>
>>> Could you post definition of cpuset_t ?
>>>
>>> It's possible that compiler was actually correct. For instance,
>>> compiler would be right to complain if cpuset_t is a packed structure,
>>> even if that structure is made of a single uint32_t field.
>>
>> It doesn't do the atomic of  cpuset_t, it does atomic of members of
>> cpuset_t which are actually long.
>> For example:
>> #define CPU_OR_ATOMIC(d, s) do {                        \
>>       __size_t __i;                                   \
>>       for (__i = 0; __i < _NCPUWORDS; __i++)          \
>>               atomic_set_long(&(d)->__bits[__i],      \
>>                   (s)->__bits[__i]);                  \
>> } while (0)
>
> BTW, how can any code like this (operating on an array) be atomic enough?

(Replying to similar questions once for all, because it is not the first time):
Protection must not be handled here, but from the callers, which know
the context.
Right now we have something like (for a typical, shared, cpumask_t functions):

volatile cpumask_t stoppedcpus;

void
f()
{
        cpumask_t c;

        ...
        c = stoppedcpus;
        (operations on c)

Whatever happens stoppedcpus may change just after read or write, then
it means we use stoppedcpus and other mask objects unlocking, we just
bear with races.

That works right now, because we really don't preview a dynamic scheme
for CPUs. They are setup at system boot and will remain like that
pretty much forever.

The per-cpu stuff also, is read only. The pm_active objects are
protected by VM locks.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein