lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <998d0e4a0803251550k24111763ve5cfe48dc5b0fc84@mail.gmail.com>
Date:	Tue, 25 Mar 2008 23:50:20 +0100
From:	"J.C. Pizarro" <jcpiza@...il.com>
To:	"Chris Snook" <csnook@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?

On 2008/3/25, Chris Snook <csnook@...hat.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.

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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ