Why /proc/cpuinfo doesn't print L1,L2,L3 caches? - Kernel

This is a discussion on Why /proc/cpuinfo doesn't print L1,L2,L3 caches? - Kernel ; $ 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 ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?

  1. Why /proc/cpuinfo doesn't print L1,L2,L3 caches?

    $ 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
    --
    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/

  2. Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?

    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

    /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.

    -- Chris
    --
    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/

  3. Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?

    On 2008/3/25, Chris Snook 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?

    J.C. Pizarro wrote:
    > On 2008/3/25, Chris Snook 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
    --
    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/

  5. Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?

    On 2008/3/25, Chris Snook wrote:
    > J.C. Pizarro wrote:
    > > On 2008/3/25, Chris Snook 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
    --
    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/

  6. Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?

    J.C. Pizarro wrote:
    > On 2008/3/25, Chris Snook wrote:
    >> J.C. Pizarro wrote:
    >> > On 2008/3/25, Chris Snook 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
    --
    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/

  7. Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?

    On Tue, Mar 25, 2008 at 10:39:39PM +0100, J.C. Pizarro wrote:

    > 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


    See x86info. http://www.codemonkey.org.uk/projects/x86info/

    Dave

    --
    http://www.codemonkey.org.uk
    --
    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/

  8. Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?

    Chris Snook wrote:

    >
    > /sys/devices/system/cpu/cpu0/cache
    >


    I do not have it:

    {pts/1}% uname -a
    Linux cooker 2.6.25-rc6-1avb #11 Fri Mar 21 20:47:27 MSK 2008 i686 Pentium
    III (Coppermine) GNU/Linux
    {pts/1}% l /sys/devices/system/cpu/cpu0
    cpuidle/
    {pts/1}% cat /proc/cpuinfo
    processor : 0
    vendor_id : GenuineIntel
    cpu family : 6
    model : 8
    model name : Pentium III (Coppermine)
    stepping : 10
    cpu MHz : 747.749
    cache size : 256 KB
    fdiv_bug : no
    hlt_bug : no
    f00f_bug : no
    coma_bug : no
    fpu : yes
    fpu_exception : yes
    cpuid level : 2
    wp : yes
    flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
    pat pse36 mmx fxsr sse
    bogomips : 1499.05
    clflush size : 32


    What am I missing?

    --
    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/

  9. consistency: temperature versus metric bytes (was: Re: Why /proc/cpuinfo doesn't print L1,L2,L3 caches?)

    On Tue, 25 Mar 2008, Chris Snook wrote:
    > I think you want this:
    >
    > /sys/devices/system/cpu/cpu0/cache
    >
    > /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.


    Oh my god! My caches run at different temperatures!! ;-)

    | anakin$ cat /sys/devices/system/cpu/cpu0/cache/index*/size
    | 64K
    | 64K
    | 512K

    Furthermore /proc/cpuinfo misses _more_ than 128 KiB:

    | anakin$ cat /proc/cpuinfo

    [...]

    | cache size : 512 KB
    ^^^^^^

    [...]

    With kind regards,

    Geert Uytterhoeven
    Software Architect

    Sony Network and Software Technology Center Europe
    The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

    Phone: +32 (0)2 700 8453
    Fax: +32 (0)2 700 8622
    E-mail: Geert.Uytterhoeven@sonycom.com
    Internet: http://www.sony-europe.com/

    Sony Network and Software Technology Center Europe
    A division of Sony Service Centre (Europe) N.V.
    Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
    VAT BE 0413.825.160 · RPR Brussels
    Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

+ Reply to Thread