From owner-svn-src-head@FreeBSD.ORG Mon Feb 9 09:51:13 2015 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A00038F; Mon, 9 Feb 2015 09:51:13 +0000 (UTC) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id DF50F869; Mon, 9 Feb 2015 09:51:12 +0000 (UTC) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id C4EB4D66DAD; Mon, 9 Feb 2015 20:51:04 +1100 (AEDT) Date: Mon, 9 Feb 2015 20:51:02 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov Subject: Re: svn commit: r278431 - head/sys/contrib/vchiq/interface/vchiq_arm In-Reply-To: <20150209090315.GD42409@kib.kiev.ua> Message-ID: <20150209203647.L1800@besplex.bde.org> References: <201502090231.t192VS6C060751@svn.freebsd.org> <20150209170045.S1037@besplex.bde.org> <20150209090315.GD42409@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=baJSDo/B c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=lNZLphJAkYUQkshLDegA:9 a=CjuIK1q_8ugA:10 Cc: svn-src-head@freebsd.org, Oleksandr Tymoshenko , svn-src-all@freebsd.org, src-committers@freebsd.org, Bruce Evans X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 09:51:13 -0000 On Mon, 9 Feb 2015, Konstantin Belousov wrote: > On Mon, Feb 09, 2015 at 05:00:49PM +1100, Bruce Evans wrote: >> On Mon, 9 Feb 2015, Oleksandr Tymoshenko wrote: >> ... >> I think the full bugs only occur when arch has strict alignment >> requirements and the alignment of the __packed objects is not known. >> This means that only lesser bugs occur on x86 (unless you enable >> alignment checking, but this arguably breaks the ABI). The compiler >> just generates possibly-misaligned full-width accesses if the arch >> doesn't have strict alignment requirements. Often the acceses turn >> out to be aligned at runtime. Otherwise, the hardware does them >> atomically, with a smaller efficiency penalty than split accesses. > > On x86 unaligned access is non-atomic. This was very visible on > Core2 CPUs where DPCPU code mishandled the alignment, resulting in > the mutexes from the per-cpu areas breaking badly. > > Modern CPUs should not lock several cache lines simultaneously either. Interesting. I thought that this was relatively easy to handle in hardware and required for compatibility, so hardware did it. This gives a reason other than efficiency to enable alignment checking so as to find all places that do misaligned accesses. I last tried this more than 20 years ago. Compilers mostly generated aligned accesses. One exception was for copying small (sub)structs. Inlining of the copy assumed maximal alignment or no alignment traps. Library functions are more of a problem. FreeBSD amd64 and i386 memcpy also assume this. Similarly for the MD mem* in the kernel. Mostly things are suitably aligned, so it is the correct optimization to not do extra work to align. Bruce