Re: /proc/cpuinfo format - arch dependent!

[lsorense@csclub.uwaterloo.ca (Lennart Sorensen)]

On Mon, May 09, 2005 at 02:00:55PM -0400, Bill Davidsen wrote:
> Linus did what was probably right then. I would agree that there is room 
> for something better now. Just to prove it could be done (not that this 
> is the only or best way):

I suspect many architecture's /proc/cpuinfo were not decided by Linus at
all, but by whoever ported linux to that architecture.

>   cpu0 {
>     socket: 0
>     chip-cache: 0
>     num-core: 2
>     per-core-cache: 512k
>     num-siblings: 2
>     sibling-cache: 0
>     family: i86
>     features: sse2 sse3 xxs bvd
>     # stepping and revision info
>   }
>   cpu1 {
>     socket: 1
>     chip-cache: 0
>     num-core: 1
>     pre-core-cache: 512k
>     num-siblings: 2
>     sibling-cache: 64k
>     family: i86
>     features: sse2 sse3 xxs bvd kook2
>     # stepping and revision info
>   }

Where does numa nodes fit into that?

> This is just proof of concept, you can have per-chip, per-core, and 
> per-sibling cache for instance, but I can't believe that anyone would 
> make a chip where the cache per core or per sibling differed, or the 
> instruction set, etc. Depending on where you buy your BS, Intel and AMD 
> will (or won't) make single and dual core chips to fit the same socket.

Have you seen the Cell processor?  Multi core with different instruction
set for the smaller execution cores than the main one.

> The complexity wasn't needed a decade ago, and I'm not sure it is now, 
> other than it being easy to display if people don't complain about 
> breaking the existing format.

But people always like complaining about all changes that they notice.

Len Sorensen