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
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
