From owner-svn-src-projects@FreeBSD.ORG Mon Oct 29 13:26:13 2012 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBD75399; Mon, 29 Oct 2012 13:26:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kostikbel-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:13d6::2]) by mx1.freebsd.org (Postfix) with ESMTP id 757008FC17; Mon, 29 Oct 2012 13:26:12 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id q9TDQ5wD033135; Mon, 29 Oct 2012 15:26:05 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id q9TDQ5Br033134; Mon, 29 Oct 2012 15:26:05 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 29 Oct 2012 15:26:05 +0200 From: Konstantin Belousov To: Andre Oppermann Subject: Re: svn commit: r238907 - projects/calloutng/sys/kern Message-ID: <20121029132605.GL73505@kib.kiev.ua> References: <201207301350.q6UDobCI099069@svn.freebsd.org> <201207301732.33474.jhb@freebsd.org> <508E35E3.9020801@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8tUgZ4IE8L4vmMyh" Content-Disposition: inline In-Reply-To: <508E35E3.9020801@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Adrian Chadd , src-committers@freebsd.org, John Baldwin , Jeff Roberson , attilio@freebsd.org, Florian Smeets , Bruce Evans , svn-src-projects@freebsd.org X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 13:26:13 -0000 --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--