runtime check of cacheline size.

runtime check of cacheline size.

[Magnus Damm]

Hi all,

Wouldn't it be nice with a glibc that works for all of us?

Idea:

Let's run-time check the cacheline-size of our cpu!

How?

First we need to make sure that the maximum cacheline size of
any PowerPC cpu is 128 bytes. (CACHELINE_MAX)
If it's anything else then it's easy to add that to the code.

Then if we should use the dcbz instruction we need at least
CACHELINE_MAX bytes aligned to a CACHELINE_MAX address. (buf)
Then we write:

address: data (32bit)

buf+16   16
buf+32   32
buf+64   64

Then we use the "dcbz" instruction on buf.

then we add together all data we've written above (sum):

32 bit data on address:

buf+64
buf+32
buf+16

then: cachelinesize = 128-sum

Easy, right?


I tried to implement it using assembler:

---- cut here ----

cachelinesize_detect:

#define CACHELINE_MAX 128

        /* use dcbz to figure out the size of a cacheline
         * on our system...
         * needs a CACHELINE_MAX bytes buffer in r3.
         * r3 should be aligned to CACHELINE_MAX too.
         */

        li      r4, 0x10        /* 16 bytes: mpc8xx, ibm4xx */
        stwx    r4, r4, r3
        li      r4, 0x20        /* 32 bytes */
        stwx    r4, r4, r3
        li      r4, 0x40        /* 64 bytes */
        stwx    r4, r4, r3
        dcbz    0, r3
        add     r5, r4, r4      /* 128 bytes */
        lwzx    r4, r4, r3
        sub     r5, r5, r4
        lwz     r4, 0x20(r3)
        sub     r5, r5, r4
        lwz     r4, 0x10(r3)
        sub     r5, r5, r4

/* now: r5 contains cacheline size */

---- cut here ----

The code is untested and I've probably use the "sub"
instruction the wrong way. You get the idea anyhow.

Who wants to adopt the idea for memset.S?

I don't really have time, sorry...

Cheers /

Magnus

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

Re: runtime check of cacheline size.

[Dan Malek]

Magnus Damm wrote:

> Wouldn't it be nice with a glibc that works for all of us?

I think the MVista glibc distribution is headed that way, and
the patches are in the pipeline to the maintainers.  There is
more than just cache line size that is processor dependent, and
all of these things have to be taken into consideration.

I know people are working on it, and are testing a variety of
implementations.

We also have to be careful about the 'dcbz' instruction.  For
some reason, the behavior of this instruction changes depending
upon the silicon revision of the MPC8xx parts.  This behavior is
more than just the way it may zero a cache line, and recently has
been trouble for the TLB handler (the 'morvek' as we now affectionately
call it :-).  Sometimes it faults, sometimes not, sometimes alignment
faults, and you may not get the proper VA when recovering the
information from the registers.  It is consistent for a particular
part, but not across the parts.  For MPC8xx, I have removed the
use of this instruction from the kernel, and we may want to consider
doing that in the library as well.  To complicate the exception
handlers (the 'morvek') to accomodate all of these different
conditions doesn't seem appropriate, and we may not be able to
catch all conditions.



	-- Dan

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