[Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[Martin.Knoblauch]

Hi,

 while trying to enhance a small hardware inventory script, I found that
cpuinfo is missing the details of L1, L2 and L3 size, although they may
be available at boot time. One could of cource grep them from "dmesg"
output, but that may scroll away on long lived systems.

 The following small patch (against 2.4.4-ac11) extracts/outputs the
cache sizes (i386 only) in arch/i386/kernel/setup.c. It also stores them
in the cpuinfo_x86 structure. This may not be necessary for a one time
usage.

--- linux-2.4.4-ac11.orig/arch/i386/kernel/setup.c      Mon May 21
14:15:27 2001
+++ linux-2.4.4-ac11/arch/i386/kernel/setup.c   Mon May 21 14:27:58 2001
@@ -67,6 +67,10 @@
  *
  *  AMD Athlon/Duron/Thunderbird bluesmoke support.
  *  Dave Jones <davej@suse.de>, April 2001.
+ *
+ *  More detailed output of L1, L2 and L3 cache sizes to /proc/cpuinfo,
if available.
+ *  Martin Knoblauch <m.knoblauch@teraport.de>, May 2001
+ *
  */

 /*
@@ -1113,6 +1117,8 @@
                printk(KERN_INFO "CPU: L1 I Cache: %dK (%d bytes/line),
D cache %dK (%d bytes/line)\n",
                        edx>>24, edx&0xFF, ecx>>24, ecx&0xFF);
                c->x86_cache_size=(ecx>>24)+(edx>>24);
+               c->x86_L1I_size = edx>>24;
+               c->x86_L1D_size = ecx>>24;
        }

        if (n < 0x80000006)     /* Some chips just has a large L1. */
@@ -1133,6 +1139,7 @@
                return;         /* Again, no L2 cache is possible */

        c->x86_cache_size = l2size;
+       c->x86_L2_size = ecx >> 16;

        printk(KERN_INFO "CPU: L2 Cache: %dK (%d bytes/line)\n",
               l2size, ecx & 0xFF);
@@ -1883,6 +1890,8 @@
                                cpuid(0x80000005,&aa,&bb,&cc,&dd);
                                /* Add L1 data and code cache sizes. */
                                c->x86_cache_size = (cc>>24)+(dd>>24);
+                               c->x86_L1I_size = cc>>24;
+                               c->x86_L1D_size = dd>>24;
                        }
                        sprintf( c->x86_model_id, "WinChip %s", name );
                        mcheck_init(c);
@@ -2141,6 +2150,10 @@
                 * SMP switching weights.
                 */
                c->x86_cache_size = l2 ? l2 : (l1i+l1d);
+               if(l1i) c->x86_L1I_size = l1i;
+               if(l1d) c->x86_L1D_size = l1d;
+               if(l2)  c->x86_L2_size = l2;
+               if(l3)  c->x86_L3_size = l3;
        }

        /* SEP CPUID bug: Pentium Pro reports SEP but doesn't have it */
@@ -2446,6 +2459,10 @@

        c->loops_per_jiffy = loops_per_jiffy;
        c->x86_cache_size = -1;
+       c->x86_L1D_size = -1;
+       c->x86_L1I_size = -1;
+       c->x86_L2_size = -1;
+       c->x86_L3_size = -1;
        c->x86_vendor = X86_VENDOR_UNKNOWN;
        c->cpuid_level = -1;    /* CPUID not detected */
        c->x86_model = c->x86_mask = 0; /* So far unknown... */
@@ -2736,9 +2753,17 @@
                                cpu_khz / 1000, (cpu_khz % 1000));
                }
 
-               /* Cache size */
+               /* Cache size(s) */
                if (c->x86_cache_size >= 0)
                        p += sprintf(p, "cache size\t: %d KB\n",
c->x86_cache_size);
+               if (c->x86_L1I_size >= 0)
+                       p += sprintf(p, "L1-I cache size\t: %d KB\n",
c->x86_L1I_size);
+               if (c->x86_L1D_size >= 0)
+                       p += sprintf(p, "L1-D cache size\t: %d KB\n",
c->x86_L1D_size);
+               if (c->x86_L2_size >= 0)
+                       p += sprintf(p, "L2 cache size\t: %d KB\n",
c->x86_L2_size);
+               if (c->x86_L3_size >= 0)
+                       p += sprintf(p, "L3 cache size\t: %d KB\n",
c->x86_L3_size);
 
                /* We use exception 16 if we have hardware math and
we've either seen it or the CPU claims it is internal */
                fpu_exception = c->hard_math && (ignore_irq13 ||
cpu_has_fpu);
--- linux-2.4.4-ac11.orig/include/asm-i386/processor.h  Mon May 21
14:16:20 2001
+++ linux-2.4.4-ac11/include/asm-i386/processor.h       Mon May 21
09:01:21 2001
@@ -44,6 +44,10 @@
        char    x86_model_id[64];
        int     x86_cache_size;  /* in KB - valid for CPUS which support
this
                                    call  */
+       int     x86_L1D_size;
+       int     x86_L1I_size;
+       int     x86_L2_size;
+       int     x86_L3_size;
        __u16   clockmul;        /* Clock multiplier */
        int     fdiv_bug;
        int     f00f_bug;


Martin
-- 
------------------------------------------------------------------
Martin Knoblauch         |    email:  Martin.Knoblauch@TeraPort.de
TeraPort GmbH            |    Phone:  +49-89-510857-309
C+ITS                    |    Fax:    +49-89-510857-111
http://www.teraport.de   |    Mobile: +49-170-4904759

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[H. Peter Anvin]

Followup to:  <3B090C81.53F163C3@TeraPort.de>
By author:    "Martin.Knoblauch" <Martin.Knoblauch@TeraPort.de>
In newsgroup: linux.dev.kernel
>
> Hi,
> 
>  while trying to enhance a small hardware inventory script, I found that
> cpuinfo is missing the details of L1, L2 and L3 size, although they may
> be available at boot time. One could of cource grep them from "dmesg"
> output, but that may scroll away on long lived systems.
> 

Any particular reason this needs to be done in the kernel, as opposed
to having your script read /dev/cpu/*/cpuid?

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[Steven Walter]

On Mon, May 21, 2001 at 08:16:18AM -0700, H. Peter Anvin wrote:
> Followup to:  <3B090C81.53F163C3@TeraPort.de>
> By author:    "Martin.Knoblauch" <Martin.Knoblauch@TeraPort.de>
> In newsgroup: linux.dev.kernel
> >
> > Hi,
> > 
> >  while trying to enhance a small hardware inventory script, I found that
> > cpuinfo is missing the details of L1, L2 and L3 size, although they may
> > be available at boot time. One could of cource grep them from "dmesg"
> > output, but that may scroll away on long lived systems.
> > 
> 
> Any particular reason this needs to be done in the kernel, as opposed
> to having your script read /dev/cpu/*/cpuid?

Wouldn't that be the same reason we have /anything/ in cpuinfo?
-- 
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
			-- George Orwell

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[Dave Jones]

On Mon, 21 May 2001, Steven Walter wrote:

> > Any particular reason this needs to be done in the kernel, as opposed
> > to having your script read /dev/cpu/*/cpuid?
> Wouldn't that be the same reason we have /anything/ in cpuinfo?

When /proc/cpuinfo was added, we didn't have /dev/cpu/*/cpuid
Now that we do, we're stuck with keeping /proc/cpuinfo for
compatability reasons.

regards,

Dave.

-- 
| Dave Jones.        http://www.suse.de/~davej
| SuSE Labs

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[David Weinehall]

On Tue, May 22, 2001 at 05:22:35AM +0200, Dave Jones wrote:
> On Mon, 21 May 2001, Steven Walter wrote:
> 
> > > Any particular reason this needs to be done in the kernel, as opposed
> > > to having your script read /dev/cpu/*/cpuid?
> > Wouldn't that be the same reason we have /anything/ in cpuinfo?
> 
> When /proc/cpuinfo was added, we didn't have /dev/cpu/*/cpuid
> Now that we do, we're stuck with keeping /proc/cpuinfo for
> compatability reasons.

AFAIK, not all processors support cpuid.


/david
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[Martin.Knoblauch]

>> 
>> Hi, 
>> 
>> while trying to enhance a small hardware inventory script, I found that 
>> cpuinfo is missing the details of L1, L2 and L3 size, although they may 
>> be available at boot time. One could of cource grep them from "dmesg" 
>> output, but that may scroll away on long lived systems. 
>> 
>
>Any particular reason this needs to be done in the kernel, as opposed 
>to having your script read /dev/cpu/*/cpuid? 
>
>        -hpa 

 terse answer: probably the same reason as for most stuff in
/proc/cpuinfo :-)

 Seriously, is there any kind of documentation on for the stuff you
mention? I am willing to learn. Isn't the cpuid just a kind of
serialnumber? The one that caused the big flame wars when Intel
introduced the concept? In any case, on my system(s) there seems to be
no device behind those files. On some systems, there is even no
"/dev/cpu" directory.

 I agree in a way that the changes to processor.h are not neccessary -
unless other parts of the kernel are interested in those values. I
probably should change that to make the thing easier to digest.

Martin

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[Martin.Knoblauch]

"Martin.Knoblauch" wrote:
> 
> >>
> >> Hi,
> >>
> >> while trying to enhance a small hardware inventory script, I found that
> >> cpuinfo is missing the details of L1, L2 and L3 size, although they may
> >> be available at boot time. One could of cource grep them from "dmesg"
> >> output, but that may scroll away on long lived systems.
> >>
> >
> >Any particular reason this needs to be done in the kernel, as opposed
> >to having your script read /dev/cpu/*/cpuid?
> >
> >        -hpa
> 
>  terse answer: probably the same reason as for most stuff in
> /proc/cpuinfo :-)
> 

 After some checking, I could have made the answer a bit less terse:

- it would require that the kernel is compiled with cpuid [module]
support
  - not everybody may want enable this, just for getting one or two
    harmless numbers.
- you would need a utility with root permission to analyze the cpuid
info. The
  cahce info does not seem to be there in clear ascii.
  - this limits my script to root users, or you need the setuid-bit on
the
    utility. Not really good for security.
- the cpuid stuff is i386 specific [today]. So are my changes. But
implementing
  them for other architectures [if there is interest in the info] would
not
  require to also implement the cpuid on other architectures. Which may
not make any
  sense at all.

 So, having the numbers in clear text in the cpuinfo file looks simpler
and safer to me, although reading /dev/cpu/*/cpuinfo maybe more
versatile [on i386] - at some cost.

 Question: are there any utilities or other uses for the cpuid device
today? Just interested. The kernel seems to work well without it.

Cheers
Martin

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[Dave Jones]

On Tue, 22 May 2001, David Weinehall wrote:

> > > Wouldn't that be the same reason we have /anything/ in cpuinfo?
> > When /proc/cpuinfo was added, we didn't have /dev/cpu/*/cpuid
> > Now that we do, we're stuck with keeping /proc/cpuinfo for
> > compatability reasons.
>
> AFAIK, not all processors support cpuid.

Fair point, but as there was limited information available
from the CPU, the likelyhood of /proc/cpuinfo getting
extended further is somewhat unlikely.
Moreso if the feature can be accomplished equally as well
in userspace (Like the original post in this thread).


regards,

Dave.

-- 
| Dave Jones.        http://www.suse.de/~davej
| SuSE Labs

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[H. Peter Anvin]

"Martin.Knoblauch" wrote:
> 
> >>
> >> Hi,
> >>
> >> while trying to enhance a small hardware inventory script, I found that
> >> cpuinfo is missing the details of L1, L2 and L3 size, although they may
> >> be available at boot time. One could of cource grep them from "dmesg"
> >> output, but that may scroll away on long lived systems.
> >>
> >
> >Any particular reason this needs to be done in the kernel, as opposed
> >to having your script read /dev/cpu/*/cpuid?
> >
> >        -hpa
> 
>  terse answer: probably the same reason as for most stuff in
> /proc/cpuinfo :-)
> 

Terse but just plain wrong.

Most stuff in /proc/cpuinfo is either hard (under some set of
circumstances) for userspace to obtain, or it is used by the kernel
itself anyway.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[H. Peter Anvin]

"Martin.Knoblauch" wrote:
> 
>  After some checking, I could have made the answer a bit less terse:
> 
> - it would require that the kernel is compiled with cpuid [module]
> support
>   - not everybody may want enable this, just for getting one or two
>     harmless numbers.

If so, then that's their problem.  We're not here to solve the problem of
stupid system administrators.

> - you would need a utility with root permission to analyze the cpuid
> info. The
>   cahce info does not seem to be there in clear ascii.

Bullsh*t.  /dev/cpu/%d/cpuid is supposed to be mode 444 (world readable.)

>   - this limits my script to root users, or you need the setuid-bit on
> the
>     utility. Not really good for security.

See above.

> - the cpuid stuff is i386 specific [today]. So are my changes. But
> implementing
>   them for other architectures [if there is interest in the info] would
> not
>   require to also implement the cpuid on other architectures. Which may
> not make any
>   sense at all.
> 
>  So, having the numbers in clear text in the cpuinfo file looks simpler
> and safer to me, although reading /dev/cpu/*/cpuinfo maybe more
> versatile [on i386] - at some cost.
> 
>  Question: are there any utilities or other uses for the cpuid device
> today? Just interested. The kernel seems to work well without it.

That is usually the case with devices -- the kernel doesn't care, why
would it?

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[Alan Cox]

> > - you would need a utility with root permission to analyze the cpuid
> > info. The
> >   cahce info does not seem to be there in clear ascii.
> 
> Bullsh*t.  /dev/cpu/%d/cpuid is supposed to be mode 444 (world readable.)

Yep. cpuid is not priviledged. There are almost no cases you would want it to
be and no cpu support for that anyway.

You would need to be root to ident some non intel processors like the 486SLC
where you need to do io port access to ports 0x22/23 (from memory)

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[Tomas Telensky]

On 21 May 2001, H. Peter Anvin wrote:

> Followup to:  <3B090C81.53F163C3@TeraPort.de>
> By author:    "Martin.Knoblauch" <Martin.Knoblauch@TeraPort.de>
> In newsgroup: linux.dev.kernel
> >
> > Hi,
> > 
> >  while trying to enhance a small hardware inventory script, I found that
> > cpuinfo is missing the details of L1, L2 and L3 size, although they may
> > be available at boot time. One could of cource grep them from "dmesg"
> > output, but that may scroll away on long lived systems.
> > 
> 
> Any particular reason this needs to be done in the kernel, as opposed

It is already done in kernel, because it's displaying :)
So, once evaluated, why not to give it to /proc/cpuinfo. I think it makes
sense and gives it things in order.

	Tomas

> to having your script read /dev/cpu/*/cpuid?

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[Dave Jones]

On Wed, 23 May 2001, Tomas Telensky wrote:

> > Any particular reason this needs to be done in the kernel, as opposed
> It is already done in kernel, because it's displaying :)
> So, once evaluated, why not to give it to /proc/cpuinfo. I think it makes
> sense and gives it things in order.

Displaying at boottime only means the function can be marked as initcode,
and freed after usage. Putting it in proc/cpuinfo means we use up
kernel space that can't be freed.

regards,

Dave.

-- 
| Dave Jones.        http://www.suse.de/~davej
| SuSE Labs

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[Martin Knoblauch]

Tomas Telensky wrote:
> 
> On 21 May 2001, H. Peter Anvin wrote:
> 
> > Followup to:  <3B090C81.53F163C3@TeraPort.de>
> > By author:    "Martin.Knoblauch" <Martin.Knoblauch@TeraPort.de>
> > In newsgroup: linux.dev.kernel
> > >
> > > Hi,
> > >
> > >  while trying to enhance a small hardware inventory script, I found that
> > > cpuinfo is missing the details of L1, L2 and L3 size, although they may
> > > be available at boot time. One could of cource grep them from "dmesg"
> > > output, but that may scroll away on long lived systems.
> > >
> >
> > Any particular reason this needs to be done in the kernel, as opposed
> 
> It is already done in kernel, because it's displaying :)
> So, once evaluated, why not to give it to /proc/cpuinfo. I think it makes
> sense and gives it things in order.
> 

 That came to my mind as an pro argument also. The work is already done
in setup.c, so why not expose it at the same place where the other stuff
is. After all, it is just a more detailed output of the already
available "cache size" line.

Martin
PS: At least, I am not being ignored :-) No need for me to complain...

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[Martin Knoblauch]

"H. Peter Anvin" wrote:
> 
> "Martin.Knoblauch" wrote:
> >
> >  After some checking, I could have made the answer a bit less terse:
> >
> > - it would require that the kernel is compiled with cpuid [module]
> > support
> >   - not everybody may want enable this, just for getting one or two
> >     harmless numbers.
> 
> If so, then that's their problem.  We're not here to solve the problem of
> stupid system administrators.
>

 They may not be stupid, just mislead :-( When Intel created the "cpuid"
Feature some way along the P3 line, they gave a stupid reason for it and
created a big public uproar. As silly as I think that was (on both
sides), the term "cpuid" is tainted. Some people just fear it like hell.
Anyway.
 
> > - you would need a utility with root permission to analyze the cpuid
> > info. The
> >   cahce info does not seem to be there in clear ascii.
> 
> Bullsh*t.  /dev/cpu/%d/cpuid is supposed to be mode 444 (world readable.)
> 

 Thanks you :-) In any case, on my system (Suse 7.1) the files are mode
400.

Martin

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[H. Peter Anvin]

Martin Knoblauch wrote:
> >
> > If so, then that's their problem.  We're not here to solve the problem of
> > stupid system administrators.
> >
> 
>  They may not be stupid, just mislead :-( When Intel created the "cpuid"
> Feature some way along the P3 line, they gave a stupid reason for it and
> created a big public uproar. As silly as I think that was (on both
> sides), the term "cpuid" is tainted. Some people just fear it like hell.
> Anyway.
> 

Ummm... CPUID has been around since the P5, and even if you have one with
the serial-number feature, Linux disables it. 

> > > - you would need a utility with root permission to analyze the cpuid
> > > info. The
> > >   cahce info does not seem to be there in clear ascii.
> >
> > Bullsh*t.  /dev/cpu/%d/cpuid is supposed to be mode 444 (world readable.)
> >
> 
>  Thanks you :-) In any case, on my system (Suse 7.1) the files are mode
> 400.
> 

It's pointless since you can execute CPUID directly in user space.  The
device is there just to support CPU selection in a multiprocessor system.

	-hpa

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[Tomas Telensky]

On Tue, 22 May 2001, H. Peter Anvin wrote:

> Martin Knoblauch wrote:
> > >
> > > If so, then that's their problem.  We're not here to solve the problem of
> > > stupid system administrators.
> > >
> > 
> >  They may not be stupid, just mislead :-( When Intel created the "cpuid"
> > Feature some way along the P3 line, they gave a stupid reason for it and
> > created a big public uproar. As silly as I think that was (on both
> > sides), the term "cpuid" is tainted. Some people just fear it like hell.
> > Anyway.
> > 
> 
> Ummm... CPUID has been around since the P5, and even if you have one with
> the serial-number feature, Linux disables it. 
> 
> > > > - you would need a utility with root permission to analyze the cpuid
> > > > info. The
> > > >   cahce info does not seem to be there in clear ascii.
> > >
> > > Bullsh*t.  /dev/cpu/%d/cpuid is supposed to be mode 444 (world readable.)
> > >
> > 
> >  Thanks you :-) In any case, on my system (Suse 7.1) the files are mode
> > 400.
> > 
> 
> It's pointless since you can execute CPUID directly in user space.  The

Yes. Recently I tried to transform whole cpuid code to a userspace
utility. Not easy, not clean... but it worked.

	Tomas

P.S.: but I still find the patch useful.

> device is there just to support CPU selection in a multiprocessor system.

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[Dave Jones]

On Wed, 23 May 2001, Tomas Telensky wrote:

> Yes. Recently I tried to transform whole cpuid code to a userspace
> utility. Not easy, not clean... but it worked.

See http://www.sourceforge.net/projects/x86info
or ftp://ftp.suse.com/pub/people/davej/x86info/

regards,

Dave.

-- 
| Dave Jones.        http://www.suse.de/~davej
| SuSE Labs

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[Dave Jones]

On Wed, 23 May 2001, Martin Knoblauch wrote:

>  They may not be stupid, just mislead :-( When Intel created the "cpuid"
> Feature some way along the P3 line, they gave a stupid reason for it and
> created a big public uproar. As silly as I think that was (on both
> sides), the term "cpuid" is tainted. Some people just fear it like hell.
> Anyway.

I think you are confusing the CPU serial number with CPUID which is
not the same. CPUID instruction has been around since late 486en.

The P3 Serial number is still disabled by default in Linux,
unless overridden with a boottime switch.

regards,

Davej.

-- 
| Dave Jones.        http://www.suse.de/~davej
| SuSE Labs

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[Martin.Knoblauch]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

Dave Jones wrote:
> 
> On Wed, 23 May 2001, Martin Knoblauch wrote:
> 
> >  They may not be stupid, just mislead :-( When Intel created the "cpuid"
> > Feature some way along the P3 line, they gave a stupid reason for it and
> > created a big public uproar. As silly as I think that was (on both
> > sides), the term "cpuid" is tainted. Some people just fear it like hell.
> > Anyway.
> 
> I think you are confusing the CPU serial number with CPUID which is
> not the same. CPUID instruction has been around since late 486en.
> 

 seems I am being confused. If that happens to me :-) ....

Martin
-- 
------------------------------------------------------------------
Martin Knoblauch         |    email:  Martin.Knoblauch@TeraPort.de
TeraPort GmbH            |    Phone:  +49-89-510857-309
C+ITS                    |    Fax:    +49-89-510857-111
http://www.teraport.de   |    Mobile: +49-170-4904759

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Card for Martin.Knoblauch --]
[-- Type: text/x-vcard; charset=us-ascii; name="Martin.Knoblauch.vcf", Size: 375 bytes --]

begin:vcard 
n:Knoblauch;Martin
tel;cell:+49-170-4904759
tel;fax:+49-89-510857-111
tel;work:+49-89-510857-309
x-mozilla-html:FALSE
url:http://www.teraport.de
org:TeraPort GmbH;C+ITS
adr:;;Garmischer Straße 4;München;Bayern;D-80339;Germany
version:2.1
email;internet:Martin.Knoblauch@TeraPort.de
title:Senior System Engineer
x-mozilla-cpt:;-7008
fn:Martin Knoblauch
end:vcard

Re: [Patch] Output of L1,L2 and L3 cache sizes to /proc/cpuinfo

[Martin.Knoblauch]

[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]

Dave Jones wrote:
> 
> On Wed, 23 May 2001, Tomas Telensky wrote:
> 
> > Yes. Recently I tried to transform whole cpuid code to a userspace
> > utility. Not easy, not clean... but it worked.
> 
> See http://www.sourceforge.net/projects/x86info
> or ftp://ftp.suse.com/pub/people/davej/x86info/
> 

 thanks for the pointer. Definitely gives some very interesting
information about ones x86 CPU. At least something to work on. The
output for different CPU types is a bit incoherent, making it difficult
to parse. That why I [still] think (yes I'm stubborn :-) that having the
cache sizes in /proc/cpuinfo in one format is a good idea. The info is
there, it is just the output. With the userland tool, you always may
have discrepancies between the kernels view and the tools view.

 But I agree, it does not *have* to go into the kernel.

Cheers
MArtin
-- 
------------------------------------------------------------------
Martin Knoblauch         |    email:  Martin.Knoblauch@TeraPort.de
TeraPort GmbH            |    Phone:  +49-89-510857-309
C+ITS                    |    Fax:    +49-89-510857-111
http://www.teraport.de   |    Mobile: +49-170-4904759

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Card for Martin.Knoblauch --]
[-- Type: text/x-vcard; charset=us-ascii; name="Martin.Knoblauch.vcf", Size: 375 bytes --]

begin:vcard 
n:Knoblauch;Martin
tel;cell:+49-170-4904759
tel;fax:+49-89-510857-111
tel;work:+49-89-510857-309
x-mozilla-html:FALSE
url:http://www.teraport.de
org:TeraPort GmbH;C+ITS
adr:;;Garmischer Straße 4;München;Bayern;D-80339;Germany
version:2.1
email;internet:Martin.Knoblauch@TeraPort.de
title:Senior System Engineer
x-mozilla-cpt:;-7008
fn:Martin Knoblauch
end:vcard