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/