From: Dag Bakke <dagb@sgi.com>
To: linux-kernel@vger.kernel.org
Subject: Inconsistent cache size reporting.?
Date: Fri, 19 Jan 2001 09:26:27 +0100 [thread overview]
Message-ID: <3A67FA33.25F188E0@sgi.com> (raw)
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/
next reply other threads:[~2001-01-19 9:39 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-19 8:26 Dag Bakke [this message]
2001-01-20 16:26 ` Inconsistent cache size reporting.? Janos Farkas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3A67FA33.25F188E0@sgi.com \
--to=dagb@sgi.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.