Inconsistent cache size reporting.?

Inconsistent cache size reporting.?

[Dag Bakke]

I have noticed something strange about the L1/L2 cache size reporting in the
2.4.0 kernel which could need a little explanation. 

It looks as if /proc/cpuinfo reports the L2 cache size on a PII, while it
reports the L1 cache size on a K6-2. 

Either that, or my external L2 cache is 64kB, and not 512 as it is supposed
to be. memtest86 reports 'cacheable memory' to be 128MB, which is according
to spec. I can verify with lmbench that I *have* a l2 cache, by switching it
on/off in bios. (Larry: any chance of detecting/measuring l2 cache size?)



My friend's system reports:

dmesg:
CPU: Before vendor init, caps: 0183f9ff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0183f9ff 00000000 00000000 00000000
CPU: After generic, caps: 0183f9ff 00000000 00000000 00000000
CPU: Common caps: 0183f9ff 00000000 00000000 00000000
CPU: Intel Pentium II (Deschutes) stepping 01

/proc/cpuinfo:
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 5
model name      : Pentium II (Deschutes)
stepping        : 1
cpu MHz         : 350.799
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
pat
pse36 mmx fxsr
bogomips        : 699.59


My own system reports:

dmesg:
CPU: Before vendor init, caps: 008021bf 808029bf 00000000, vendor = 2
CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line)
CPU: After vendor init, caps: 008021bf 808029bf 00000000 00000002
CPU: After generic, caps: 008021bf 808029bf 00000000 00000002
CPU: Common caps: 008021bf 808029bf 00000000 00000002
CPU: AMD-K6(tm) 3D processor stepping 0c

/proc/cpuinfo:
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 5
model           : 8
model name      : AMD-K6(tm) 3D processor
stepping        : 12
cpu MHz         : 501.121
cache size      : 64 KB         <-------????
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 pge mmx syscall 3dnow
k6_mtrr
bogomips        : 999.42


I also note that performance on this system isn't quite what I would expect
it to be. compiling glibc 2.1.3 takes longer time on my system than on a
PII-366.
A Celeron 300 outperforms the K6 when running 'mpeg2dec -o null'. Is the K6-2
really this bad? Or is it my memory latency/bandwidth which is hurting me?

lmbench data. Notice that the 2nd run is with external cache switched off.
Kernel is 2.4.0-ac6.

*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------
Host                OS  Pipe AF    TCP  File   Mmap  Bcopy  Bcopy  Mem   Mem
                             UNIX      reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
dagb      Linux 2.4.0-a   93   56   41     89    272     73     73  272   103
dagb      Linux 2.4.0-a   54   38   28     59    270     79     80  270   112

Memory latencies in nanoseconds - smaller is better
    (WARNING - may not be correct, check graphs)
---------------------------------------------------
Host                 OS   Mhz  L1 $   L2 $    Main mem    Guesses
--------- -------------  ---- ----- ------    --------    -------
dagb      Linux 2.4.0-a   501 3.996    133    235
dagb      Linux 2.4.0-a   501 3.996    233    238    No L2 cache?



Regards,

Dag B
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Inconsistent cache size reporting.?

[Janos Farkas]

On 2001-01-19 at 09:26:27, Dag Bakke wrote:
> It looks as if /proc/cpuinfo reports the L2 cache size on a PII, while
> it reports the L1 cache size on a K6-2. 

The kernel can only detect (at least via "fetch-info-from-cpu" methods)
the size of internal caches.  If there is more level of them, it reports
the latter one (the one more closer to the memory), as all but the most
recent CPU caching techniques do not add up for multiple levels of
caches, so only the larger is the effective size.

I guess the entry in cpuinfo is just a hint for user programs to help
optimizing the size of data to be worked on.  External caches (mostly
found on Socket7 motherboards nowadays) don't really help tight loops,
just improve the memory access timings a bit, so they don't really
count..

So, on a PII/PIII, you'll see the L2 cache size reported (as it's
internal to the CPU), while on a K6, K6-2, you'll see the L1 cache size
(total), since the external (motherboard) caches are invisible to the
kernel.  (Ie. not easily recoverable).  On a K6-III, however, you'd see
the L2 cache as well; but the external cache is still invisible to the
kernel.

> I also note that performance on this system isn't quite what I would expect
> it to be. compiling glibc 2.1.3 takes longer time on my system than on a
> PII-366.
> A Celeron 300 outperforms the K6 when running 'mpeg2dec -o null'. Is the K6-2
> really this bad? Or is it my memory latency/bandwidth which is hurting me?

I seem to remember, that the K6 architecture is quite cache hungry,
that's why the K6-III is noticeably better than the K6-2.  Also, the FPU
is not quite the same than Intel's one, it's not obviously worse, but
needs different optimizations, or "3DNow!" supporting programs to reach
the same level of performance.  Your experience at compiling sounds a
bit surprising, a K6-III at 400 MHz seemed to perform much better than
anything on comparable frequencies, and the K6-2 was still quite similar
to Celerons, so maybe your motherboard has some quirky issues around
memory and/or cache, maybe your disks/controller is much worse on the K6
system, but what the kernel does report is nothing to worry about...

Janos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/