Date: Mon, 29 Oct 2012 15:26:05 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Andre Oppermann <andre@freebsd.org> Cc: Adrian Chadd <adrian@freebsd.org>, src-committers@freebsd.org, John Baldwin <jhb@freebsd.org>, Jeff Roberson <jeff@freebsd.org>, attilio@freebsd.org, Florian Smeets <flo@freebsd.org>, Bruce Evans <bde@freebsd.org>, svn-src-projects@freebsd.org Subject: Re: svn commit: r238907 - projects/calloutng/sys/kern Message-ID: <20121029132605.GL73505@kib.kiev.ua> In-Reply-To: <508E35E3.9020801@freebsd.org> References: <201207301350.q6UDobCI099069@svn.freebsd.org> <CAJ-FndBj8tpC_BJXs_RH8sG2TBG8yA=Lxu3-GTVT9Ap_zOCuVQ@mail.gmail.com> <CAJ-FndDnO7wjnWPV0tTu%2BUGHjsxa3YDarMxmyei3ZmjLAFvRkQ@mail.gmail.com> <201207301732.33474.jhb@freebsd.org> <CAJ-FndD5EO12xsWOAe6u0EvX00q33wxO4OivnGjzj0=T2Oe8uA@mail.gmail.com> <CAJ-FndCRg0UCThFkatp=tw7rUWWCvhsApLE=iztLpxpGBC1F9w@mail.gmail.com> <CAJ-FndBqV2uD8Th9ePtxyJwhMAPzY3AXA5cQ7HszLp=%2BfSpHTA@mail.gmail.com> <CAJ-FndDPLmkpAJeGVN2wgbhdgHYezyUV-PPvH9e-CA7Go7HG3A@mail.gmail.com> <CAJ-VmonMQgT7rGOhZ-hq%2B3R%2BSbdNfTBNHLAWW1xwicHy1cb2BQ@mail.gmail.com> <508E35E3.9020801@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--8tUgZ4IE8L4vmMyh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Oct 29, 2012 at 08:53:07AM +0100, Andre Oppermann wrote:
> On 29.10.2012 03:25, Adrian Chadd wrote:
> > So colour me a bit silly, but why didn't you use an atomic here for
> > that single variable, rather than a memory barrier alone?
>=20
> Because sched_pin() can only be used within a critical section and
> thus guarantees that we stay on the same CPU. So we don't have to
> worry about full SMP visibility and preventing just the compiler from
> reordering or register caching the value.
This is wrong, both for preassumption ('sched_pin() can only be used
within a critical section') and for the conclusion. sched_pin() does
not require the containing critical section for use.
sched_pin() is a thread-local operation. This is why we should only
worry about local reordering, since mi_switch() must be executed
by current processor to switch the current thread.
I agree with Attilio patch, it seems that normal C rules are not enough
to guarantee that no harmful reordering, which can be observed through
the async events on current core, happens.
>=20
> The atomic functions do a full bus lock cycle and a CPU pipeline
> flush (in most cases) to make sure that the new value is seen on
> all CPU's at the same time.
>=20
> On SMP architectures and shared data structures you have to worry
> about three things:
> - compiler reordering (instruction optimizations)
> - cpu pipelines
> - memory and cache coherency
>=20
> To be honest it takes some time to understand the different behaviors
> and then to be able to reason about it. There is quite some nice and
> dense literature out there about atomics. Googling turns up the
> important ones.
>=20
> > I feel slightly nitpicky about it, but this stuff rubs me up slightly
> > the wrong way, same as the "don't worry about using atomics for 32 bit
> > set/reads, as those are guaranteed to be atomic on all of the
> > platforms we use" done what, last year or so.
>=20
> Well, we have to have a baseline somewhere. Many architectures don't
> even have atomics for less than 32 bits.
>=20
> --=20
> Andre
--8tUgZ4IE8L4vmMyh
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)
iEYEARECAAYFAlCOg+wACgkQC3+MBN1Mb4jGIQCglBktV0F9FBNnXXAsgxguNgQ2
X4sAoLZUeVFNGSkVme5+jfOz4bLoMj6M
=hMxy
-----END PGP SIGNATURE-----
--8tUgZ4IE8L4vmMyh--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121029132605.GL73505>