login
Login
/
Register
Search
Search this site:
Forums
News
Blogs
Features
Site
Home
»
Mailing list archives
»
linux-kernel
»
2008
»
March
»
25
Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?
view
thread
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
[view in full thread]
From: Chris Snook
Subject:
Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?
Date: Tuesday, March 25, 2008 - 4:14 pm
J.C. Pizarro wrote:
quoted text
> On 2008/3/25, Chris Snook <csnook@redhat.com> wrote: >> J.C. Pizarro wrote: >> > On 2008/3/25, Chris Snook <csnook@redhat.com> wrote: >> >> J.C. Pizarro wrote: >> >> > $ cat /proc/cpuinfo >> >> > processor : 0 >> >> > vendor_id : AuthenticAMD >> >> > cpu family : 15 >> >> > model : 47 >> >> > model name : AMD Athlon(tm) 64 Processor 3200+ >> >> > ... >> >> > cache size : 512 KB >> >> > ... >> >> > >> >> > The cache size is currently misinformed. It's not the real size because >> >> > it's 64+64+512 KiB = 640 KiB, not 512 KB. >> >> > >> >> > How can i know what hw-caches use the processors? >> >> > The current kernel doesn't know well what hw-caches uses. >> >> > >> >> > The good proposal is by example (the data below are not real): >> >> > * In old AMD Athlon64: >> >> > >> >> > cache L1 : 64 KiB I + 64 KiB D, 64 B line, direct way, ... >> >> > cache L2 : 512 KiB I+D-shared, exclusive, 128 associative way, ... >> >> > cache L3 : none >> >> > >> >> > * In Intel Core Duo: >> >> > processor : 0 >> >> > cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ... >> >> > cache L2 : 2048 KiB Cores-shared, inclusive, 128 associative way, ... >> >> > cache L3 : none >> >> > >> >> > processor : 1 >> >> > cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ... >> >> > cache L2 : 2048 KiB cores-shared, inclusive, 128 associative way, ... >> >> > cache L3 : none >> >> > >> >> > * In Quad: >> >> > processor : 0 >> >> > cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ... >> >> > cache L2 : 2048+2048 KiB pair-cores-shared, inclusive, 128 >> >> > associative way, ... >> >> > cache L3 : none >> >> > ... >> >> > processor : 3 >> >> > cache L1 : 32 KiB I + 32 KiB D, 64 B line, direct way, ... >> >> > cache L2 : 2048+2048 KiB pair-cores-shared, inclusive, 128 >> >> > associative way, ... >> >> > cache L3 : none >> >> > >> >> > It above is an example, put your symbols to /proc/cpuinfo in a >> >> > convenient manner. >> >> > >> >> > Good bye ;) >> >> >> >> >> >> I think you want this: >> >> >> >> /sys/devices/system/cpu/cpu0/cache >> > >> > Thanks, but there is not easier manner to print the properties of hw-caches >> > unless printing recursively this tree /sys/devices/system/cpu/cpu[0-9]+/cache/ >> > that they are only numbers without symbolic fields. >> >> >> Then use dmidecode. It's all in one place, and everyone expects it to be far >> too long to read at a glance. >> >> >> > There is not manner to know the speed (in MHz) of the L1, L2 and L3 caches. >> > >> >> /proc/cpuinfo is intended to give a general summary of certain properties of the >> >> processor that tend to be particularly interesting, and present them all in one >> >> place. It is not intended to expose everything the kernel knows about every >> >> processor on the system. >> > >> > /proc/cpuinfo doesn't give a general summary because it gives superfluous info. >> > >> > I think that it's better to refactorize /proc/cpuinfo still more. >> > >> > ( >> > ... fields common to all present processors known by the kernel .... >> > [ to warn if the values are differents between cores ] >> > ) >> > ( >> > ... specific fields for each processor ... by example: >> > >> > processor : 0 >> > cpu MHz : 2000.000 # normal clocked >> > bogomips : 4010.63 >> > processor : 1 >> > cpu MHz : 500.000 # underclocked for energy saving ... >> > bogomips : 1003.20 >> > >> > ) >> > >> > I think that all the cores are equals in almost non-weird systems. >> > With this scheme, the cpuinfo's reports will be smaller than before, >> > and non-superfluous. >> >> >> It's precisely that sort of weirdness we want to be able to catch at a glance. >> These days, there is no possible way to make /proc/cpuinfo satisfy everyone and >> still be compact. That's why we mostly leave it alone and put all the fun stuff >> in /sys, which is much better suited to the ever-increasing complexity of modern >> hardware. >> >> If we refactor /proc/cpuinfo, it will break all sorts of things that use that >> information to get an idea of what the system is running on. All of the info is >> there in /sys now anyway, so if you want a different format, write your own >> userspace tool to scrape it together. There's absolutely no need to implement >> this purely cosmetic data formatting in the kernel. >> >> >> -- Chris > > Well, i understand as if this cosmetic data formatting can break the grep of > some applications. > > But if the modern PC has 6 or 8 cores then it prints an equivalent to > x6 or x8 common pages in a small xterm console of 80x25 although > the panoramic TFT is bigger as 23' 1900x1200 pixels. > > Tomorrow, 32 cores, it prints x32 instead of x8. > Soon, it will need cosmetic data formatting. > > Hahahaha ;)
All the more reason to use an interface that allows you to pick and choose the data you want, like /sys. -- Chris --
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
Messages in current thread:
Why /proc/cpuinfo doesn't print L1,L2,L3 caches?
, J.C. Pizarro
, (Tue Mar 25, 2:39 pm)
Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?
, Chris Snook
, (Tue Mar 25, 2:57 pm)
Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?
, J.C. Pizarro
, (Tue Mar 25, 3:50 pm)
Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?
, Chris Snook
, (Tue Mar 25, 3:59 pm)
Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?
, J.C. Pizarro
, (Tue Mar 25, 4:10 pm)
Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?
, Chris Snook
, (Tue Mar 25, 4:14 pm)
Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?
, Dave Jones
, (Tue Mar 25, 6:39 pm)
consistency: temperature versus metric bytes (was: Re: Why ...
, Geert Uytterhoeven
, (Wed Mar 26, 1:54 am)
Navigation
Create content
Mailing list archives
Recent posts
Popular discussions
linux-kernel
:
Gene Heskett
Re: New thread RDSL, post-2.6.20 kernels and amanda (tar) miss-fires
Ray Lee
Re: New thread RDSL, post-2.6.20 kernels and amanda (tar) miss-fires
Michael Moore
Re: underage models, pre teen models, lolita porn, young preteens, little lolitas
Ray Lee
Re: New thread RDSL, post-2.6.20 kernels and amanda (tar) miss-fires
Gene Heskett
Re: New thread RDSL, post-2.6.20 kernels and amanda (tar) miss-fires
git
:
Junio C Hamano
Re: [Discussion] cherry-picking a merge
Gary Yang
fatal: did you run git update-server-info on the server? mv post-update.sample pos...
Uwe
Re: "bash: git-upload-pack: command not found" ??
Oliver Hoffmann
git init --bare versus git --bare init
Michael S. Tsirkin
git-kill: rewrite history removing a commit
openbsd-misc
:
Paul M
Corrupted RAIDFrame device
Ted Unangst
Re: OpenSMTPd actual development and integration
Netmaffia.hu
Tini Lányok AKCIÓBAN OTTHON
BetClic
Benfica vs Porto - Qual o seu palpite?
openbsd
observed spamd behavior
linux-netdev
:
Francois-Xavier Le Bail
[PATCH v2] net: typos in comments in include/linux/igmp.h
Jamie Lokier
Re: [2/3] POHMELFS: Documentation.
Stephen Hemminger
Re: vlan JMicron Technologies, Inc. JMC250 PCI Express Gigabit Ethernet
David Miller
Re: [net-next-2.6 PATCH 5/5] be2net: remove BUG_ON() when be2net runs out of mccq ...
Sage Weil
Re: [2/3] POHMELFS: Documentation.
git-commits-head
:
Linux Kernel Mailing List
Remove empty comment in acpi/power.c
Linux Kernel Mailing List
powerpc/kexec: Add support for FSL-BookE
Linux Kernel Mailing List
USB: rename usb_buffer_alloc() and usb_buffer_free()
Linux Kernel Mailing List
powerpc/fsl-booke: Move the entry setup code into a seperate file
Linux Kernel Mailing List
cfq-iosched: add message logging through blktrace
Colocation donated by:
Syndicate