Hello Andrew,
On Tue, 2009-05-12 at 23:21 -0700, Andrew Morton wrote:
> On Tue, 12 May 2009 12:44:42 +0530 Jaswinder Singh Rajput <[email protected]> wrote:
>
> > + "ext cpuid level\t: 0x%x\n"
>
> It's unobvious what "ext" means. External?
>
> Can we make it "extended cpuid level"?
extended cpuid level will look like this :
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
extended cpuid level: 0x80000008
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc pebs bts pni dtes64 monitor ds_cpl cid
Is this OK ?
Thanks,
--
JSR
Jaswinder Singh Rajput wrote:
> Hello Andrew,
>
> On Tue, 2009-05-12 at 23:21 -0700, Andrew Morton wrote:
>> On Tue, 12 May 2009 12:44:42 +0530 Jaswinder Singh Rajput <[email protected]> wrote:
>>
>>> + "ext cpuid level\t: 0x%x\n"
>> It's unobvious what "ext" means. External?
>>
>> Can we make it "extended cpuid level"?
>
> extended cpuid level will look like this :
>
> fpu : yes
> fpu_exception : yes
> cpuid level : 5
> wp : yes
> extended cpuid level: 0x80000008
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc pebs bts pni dtes64 monitor ds_cpl cid
>
The more I'm thinking about this I think it was a mistake to put cpuid
level: there in the first place, too. My opinion is increasingly to
leave this to x86info or other user-space tools.
-hpa
On Fri, 2009-06-05 at 13:55 -0700, H. Peter Anvin wrote:
> Jaswinder Singh Rajput wrote:
> > Hello Andrew,
> >
> > On Tue, 2009-05-12 at 23:21 -0700, Andrew Morton wrote:
> >> On Tue, 12 May 2009 12:44:42 +0530 Jaswinder Singh Rajput <[email protected]> wrote:
> >>
> >>> + "ext cpuid level\t: 0x%x\n"
> >> It's unobvious what "ext" means. External?
> >>
> >> Can we make it "extended cpuid level"?
> >
> > extended cpuid level will look like this :
> >
> > fpu : yes
> > fpu_exception : yes
> > cpuid level : 5
> > wp : yes
> > extended cpuid level: 0x80000008
> > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc pebs bts pni dtes64 monitor ds_cpl cid
> >
>
> The more I'm thinking about this I think it was a mistake to put cpuid
> level: there in the first place, too. My opinion is increasingly to
> leave this to x86info or other user-space tools.
>
cpuid level is as important as cpu family, model and stepping.
For Intel, in some cases cpuid level is more important then cpu family,
model and stepping. Like you cannot tell by looking at cpu family, model
and stepping which model is new and which is old like 05_01 or 06_1A or
0F_03H ?
But by looking at cpuid level and extended cpuid level you can tell
which is new and which is old and which supports more features.
So cpuid level and extended cpuid level is better scale than cpu family,
model and stepping. So I think hiding this valuable information is a
crime.
Thanks,
--
JSR
Hello Peter,
On Sat, 2009-06-06 at 09:53 +0530, Jaswinder Singh Rajput wrote:
> On Fri, 2009-06-05 at 13:55 -0700, H. Peter Anvin wrote:
> > Jaswinder Singh Rajput wrote:
> > > Hello Andrew,
> > >
> > > On Tue, 2009-05-12 at 23:21 -0700, Andrew Morton wrote:
> > >> On Tue, 12 May 2009 12:44:42 +0530 Jaswinder Singh Rajput <[email protected]> wrote:
> > >>
> > >>> + "ext cpuid level\t: 0x%x\n"
> > >> It's unobvious what "ext" means. External?
> > >>
> > >> Can we make it "extended cpuid level"?
> > >
> > > extended cpuid level will look like this :
> > >
> > > fpu : yes
> > > fpu_exception : yes
> > > cpuid level : 5
> > > wp : yes
> > > extended cpuid level: 0x80000008
> > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe constant_tsc pebs bts pni dtes64 monitor ds_cpl cid
> > >
> >
> > The more I'm thinking about this I think it was a mistake to put cpuid
> > level: there in the first place, too. My opinion is increasingly to
> > leave this to x86info or other user-space tools.
> >
>
> cpuid level is as important as cpu family, model and stepping.
>
> For Intel, in some cases cpuid level is more important then cpu family,
> model and stepping. Like you cannot tell by looking at cpu family, model
> and stepping which model is new and which is old like 05_01 or 06_1A or
> 0F_03H ?
>
> But by looking at cpuid level and extended cpuid level you can tell
> which is new and which is old and which supports more features.
>
> So cpuid level and extended cpuid level is better scale than cpu family,
> model and stepping. So I think hiding this valuable information is a
> crime.
>
Highest Value in EAX
Intel 64 or IA-32 Processors Basic Information Extended Function
Information
Earlier Intel486 Processors CPUID Not Implemented CPUID Not Implemented
Later Intel486 Processors and 01H Not Implemented
Pentium Processors
Pentium Pro and Pentium II 02H Not Implemented
Processors, Intel Celeron
Processors
Pentium III Processors 03H Not Implemented
Pentium 4 Processors 02H 80000004H
Intel Xeon Processors 02H 80000004H
Pentium M Processor 02H 80000004H
Pentium 4 Processor 05H 80000008H
supporting Hyper-Threading
Technology
Pentium D Processor (8xx) 05H 80000008H
Pentium D Processor (9xx) 06H 80000008H
Intel Core Duo Processor 0AH 80000008H
Intel Core 2 Duo Processor 0AH 80000008H
Intel Xeon Processor 3000, 0AH 80000008H
5100, 5200, 5300, 5400
Series
Intel Core 2 Duo Processor 0DH 80000008H
8000 Series
Intel Xeon Processor 5200, 0AH 80000008H
5400 Series
Intel Atom Processor 0AH 80000008H
Intel Core i7 Processor 0BH 80000008H
cpuid level and extended cpuid level tells the information about Intel
processor model.
Do you still think it is useless and should not be present
in /proc/cpuinfo .
Thanks,
--
JSR
>>>>
>>> The more I'm thinking about this I think it was a mistake to put cpuid
>>> level: there in the first place, too. My opinion is increasingly to
>>> leave this to x86info or other user-space tools.
>>>
>> cpuid level is as important as cpu family, model and stepping.
>>
>> For Intel, in some cases cpuid level is more important then cpu family,
>> model and stepping. Like you cannot tell by looking at cpu family, model
>> and stepping which model is new and which is old like 05_01 or 06_1A or
>> 0F_03H ?
>>
>> But by looking at cpuid level and extended cpuid level you can tell
>> which is new and which is old and which supports more features.
>>
>> So cpuid level and extended cpuid level is better scale than cpu family,
>> model and stepping. So I think hiding this valuable information is a
>> crime.
>
> cpuid level and extended cpuid level tells the information about Intel
> processor model. Do you still think it is useless and should not be present
> in /proc/cpuinfo .
>
I think it's pointless, because if you're doing this kind of stuff you
might as well talk to CPUID directly. We have a CPUID interface
already. The kernel isn't meant to replicate x86info or any of those
tools -- it really can't, and at that point why stop at x86info... we
could replicate arbitrary applications at that point.
As far as extended CPUID, why only the 0x0000 and 0x8000 ranges?
Transmeta used 0x8086 and VIA uses 0xC000, but we don't even cache those
internally, nevermind display them.
I'm not really all that doctrinal about this, but I'd like to get a
decent answer to the question "where does it stop, *and why*". It's a
slippery slope, and without a target, it goes on forever.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Wed, Jun 10, 2009 at 10:14:09AM -0700, H. Peter Anvin wrote:
> >>>>
> >>> The more I'm thinking about this I think it was a mistake to put cpuid
> >>> level: there in the first place, too. My opinion is increasingly to
> >>> leave this to x86info or other user-space tools.
> >>>
> >> cpuid level is as important as cpu family, model and stepping.
> >>
> >> For Intel, in some cases cpuid level is more important then cpu family,
> >> model and stepping. Like you cannot tell by looking at cpu family, model
> >> and stepping which model is new and which is old like 05_01 or 06_1A or
> >> 0F_03H ?
> >>
> >> But by looking at cpuid level and extended cpuid level you can tell
> >> which is new and which is old and which supports more features.
> >>
> >> So cpuid level and extended cpuid level is better scale than cpu family,
> >> model and stepping. So I think hiding this valuable information is a
> >> crime.
> >
> > cpuid level and extended cpuid level tells the information about Intel
> > processor model. Do you still think it is useless and should not be present
> > in /proc/cpuinfo .
> >
>
> I think it's pointless, because if you're doing this kind of stuff you
> might as well talk to CPUID directly. We have a CPUID interface
> already. The kernel isn't meant to replicate x86info or any of those
> tools -- it really can't, and at that point why stop at x86info... we
> could replicate arbitrary applications at that point.
>
> As far as extended CPUID, why only the 0x0000 and 0x8000 ranges?
> Transmeta used 0x8086 and VIA uses 0xC000, but we don't even cache those
> internally, nevermind display them.
>
> I'm not really all that doctrinal about this, but I'd like to get a
> decent answer to the question "where does it stop, *and why*". It's a
> slippery slope, and without a target, it goes on forever.
I still fail to see a real use case which requires adding that info to
the kernel and querying CPUID directly is _absolutely_ not an option.
This is what the decisive argument should be and not some "but we have
already this and that in there." Otherwise its like painting a broken
car pink - it's still broken.
--
Regards/Gruss,
Boris.
Operating | Advanced Micro Devices GmbH
System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. M?nchen, Germany
Research | Gesch?ftsf?hrer: Thomas M. McCoy, Giuliano Meroni
Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis M?nchen
(OSRC) | Registergericht M?nchen, HRB Nr. 43632
Borislav Petkov wrote:
>>
>> I'm not really all that doctrinal about this, but I'd like to get a
>> decent answer to the question "where does it stop, *and why*". It's a
>> slippery slope, and without a target, it goes on forever.
>
> I still fail to see a real use case which requires adding that info to
> the kernel and querying CPUID directly is _absolutely_ not an option.
> This is what the decisive argument should be and not some "but we have
> already this and that in there." Otherwise its like painting a broken
> car pink - it's still broken.
>
Exactly, the question is where does it stop *and why* -- give a coherent
argument why drawing a line at any one particular place makes sense.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.