progress on l2cr

[Timothy A. Seufert]

At 11:25 PM -0400 8/5/00, Giuliano Pochini wrote:
>>  >> >Is there any reason to keep the L2 cache data-only ?
>>  >>
>>  >> There are some rare cases where it can be useful, yes. Like when flushing
>>  >> it, to avoid the flush code to pollute it.
>>  >
>>  >A few bytes inside a 1MB cache are't a problem IMHO. Anyway I
>>enabled it and
>>  >performance compiling programs is 15% lower.
>>
>>  You have no reason to enable "data only" in normal use. It's used during
>>  the flush cycle of the cache to avoid polluting it while the flush code
>>  runs, but it's set and unset automatically, so you don't need to care.
>
>Ok, but /proc/.../l2cr tells it's data-only at boot.

It's lying.

There is a longstanding bug in the kernel L2CR printout routine.  The
kernel routine prints "data only" if the L2DO bit in L2CR is 0.
However, the actual meaning of this bit is 0 = data only mode off, 1
= data only mode on.

This kernel bug probably happened because early revisions of
Motorola's MPC750 manual have several errors in the L2CR section,
including an error about the interpretation of L2DO.  Early revision
Motorola processor manuals are very dangerous things and should not
be relied upon to get anything right (you should see the errata list
for the MPC8260 manual).

Unfortunately, this documentation-caused kernel bug seems to have
slipped through the cracks.


Ben, could you get this patch to fix L2CR reporting into the official
kernel?  It does the following things:

1. Fixes L2DO reporting as discussed above.

2. Fixes cache type reporting (the 2-bit cache memory type field
should be masked using a mask value of 0x03 not 0x02).

3. Sanitizes code so that only one method is used to extract bit
fields from L2CR (better readability)

4. Uses a more sensible format for reporting the L2 cache clock (the
old "+2 clock", "+1.5 clock" stuff doesn't make sense, since we're
reporting the ratio between the processor core clock and the L2 cache
clock, not a delta.)

5. Saves a few bytes of memory by having shorter clock ratio string constants.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ppc_htab.c.patch
Type: application/octet-stream
Size: 1460 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20000806/6b9aec4d/attachment.obj>
-------------- next part --------------

   Tim Seufert