lkml.org 
[lkml]   [2008]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?
J.C. Pizarro wrote:
> 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


\
 
 \ /
  Last update: 2008-03-26 00:17    [W:0.381 / U:0.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site