Date: Fri, 13 May 2011 15:50:47 +0200 From: Attilio Rao <attilio@freebsd.org> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-projects@freebsd.org, Artem Belevich <art@freebsd.org>, src-committers@freebsd.org, Warner Losh <imp@freebsd.org>, Oleksandr Tymoshenko <gonzo@freebsd.org> Subject: Re: svn commit: r221614 - projects/largeSMP/sys/powerpc/include Message-ID: <BANLkTinv9=iu8yzJD_ji4D6_txs173Kkxw@mail.gmail.com> In-Reply-To: <20110513221936.X1161@besplex.bde.org> References: <201105080039.p480doiZ021493@svn.freebsd.org> <BANLkTi=e7GtBM-PTq9yJHSLRoaOWh62AeA@mail.gmail.com> <BANLkTiktwEvRktZrGOqKKB2iSB99a3Jw=g@mail.gmail.com> <BANLkTik17r-XampEdO%2BsQ7aMOL_SDyhG=g@mail.gmail.com> <BANLkTinaWDcaiZiB3G5Szoaho1jVSeniMA@mail.gmail.com> <BANLkTimj3ohmvACmvcPa3yrdsUj=4D2V3Q@mail.gmail.com> <BANLkTikSgEXZz8vjj7kuyeWQE_oKqzB8ug@mail.gmail.com> <BANLkTinHGpL5tC3-5jOPUq6bJ2Ks7j_Dww@mail.gmail.com> <BANLkTi=DOD9p-YUMm33D5ZShTjS_Q1hEvg@mail.gmail.com> <BANLkTikj%2Bszgd%2BptzD6y%2BofPs%2B8bR7Z8ew@mail.gmail.com> <20110513221936.X1161@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2011/5/13 Bruce Evans <brde@optusnet.com.au>:
> On Thu, 12 May 2011, Attilio Rao wrote:
>
>> 2011/5/12 Artem Belevich <art@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 =C2=A0cpuset_t, it does atomic of members of
>> cpuset_t which are actually long.
>> For example:
>> #define CPU_OR_ATOMIC(d, s) do { =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\
>> =C2=A0 =C2=A0 =C2=A0 __size_t __i; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 \
>> =C2=A0 =C2=A0 =C2=A0 for (__i =3D 0; __i < _NCPUWORDS; __i++) =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0\
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 atomic_set_long(&(d)->_=
_bits[__i], =C2=A0 =C2=A0 =C2=A0\
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (s)->__bi=
ts[__i]); =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\
>> } 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 ti=
me):
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 function=
s):
volatile cpumask_t stoppedcpus;
void
f()
{
cpumask_t c;
...
c =3D 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
--=20
Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTinv9=iu8yzJD_ji4D6_txs173Kkxw>