Dcbz vs dcbzl

Benjamin Herrenschmidt benh at kernel.crashing.org
Thu Mar 25 10:32:29 EST 2004


On Thu, 2004-03-25 at 05:32, David Ober wrote:
> Hi
>
>   Is anyone working on the compile/assembler to support the dcbzl
> instruction.  Since the dcbz operates on a 32 byte line and the dcbzl
> is on the 128 bytes there is a warning on the Apple developers page
> about not using the dcbz instruction on the G5.  There are two
> references in the 32 bit kernel that are causing problems in some
> imbedded application.  When attempting to update to use the dcbzl I
> find that the assembler does not yet understand it.

Well, to be clear, "dcbz" only operates on 32 bytes when the special
HID5 compatiblity bit that apple added to the 970 is set. This is _NOT_
the normal case and this bit isn't set in linux unless you explicitely
set it by modifying the kernel, as discussed for a while now by Chris
Friesen.

Your mail seem to imply there is a kernel bug of some sort of whatever,
which is _NOT_ the case. That whole dcbz vs. dcbzl thing was added for
Apple to cope with broken existing code that makes assumption about the
cache line size. Previous ppc64 CPUs had already a 128 bytes cache line
and by setting the HID5 bit, keep in mind that you are taking the risk
of breaking existing 64 bits binaries that make the same (broken)
assumption on the cache line size.

I'll try to put my hand on some binutils folks, but in general, such a
request should be posted to binutils mailing lists.

Note that the proper fix is for code to use the cache line size as
provided by the ELF AUX tables by the kernel to any launched executable,
though if you set this magic HID5 bit, you break perfectly valid code
that correctly reads the cache line size and gets a value of 128 passed
down by the kernel.

To properly handle this bit, we would have to ammend the ABI to add a
way for the kernel to inform userland that a different cache line size
applies to dcbz, or to only set this HID5 bit for special processes that
have some magic ELF flag set or whatever (& context switch it).

Ben.


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/





More information about the Linuxppc64-dev mailing list