Montecito processor family

Montecito processor family

[Menyhart, Zoltan]

Could someone, please, tell me what the family of the
Montecito processor will be in /proc/cpuinfo?
(text representation, numerical ID)

Thanks,

Zoltan

RE: Montecito processor family

[Yu, Fenghua]

The family number is 32. Currently there is no text representation yet.
Probably a piece of text should be there later.

Thanks.

-Fenghua

-----Original Message-----
From: linux-ia64-owner@vger.kernel.org
[mailto:linux-ia64-owner@vger.kernel.org] On Behalf Of Menyhart, Zoltan
Sent: Monday, June 13, 2005 12:04 PM
To: linux-ia64@vger.kernel.org
Subject: Montecito processor family 

Could someone, please, tell me what the family of the
Montecito processor will be in /proc/cpuinfo?
(text representation, numerical ID)

Thanks,

Zoltan


-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Montecito processor family

[Takayoshi Kochi]

Hi,

I see that nothing has happend to Montecito's family name
in both Linus' and Tony's tree since then.

Is adding 'Itanium 2' for case 0x20 enough or do we need
something different?

Intel people may want to decide what it should be, according to
their marketing/branding plan ;)

From: "Yu, Fenghua" <fenghua.yu@intel.com>
Subject: RE: Montecito processor family 
Date: Mon, 13 Jun 2005 12:17:34 -0700

> The family number is 32. Currently there is no text representation yet.
> Probably a piece of text should be there later.
> 
> Thanks.
> 
> -Fenghua
> 
> -----Original Message-----
> From: linux-ia64-owner@vger.kernel.org
> [mailto:linux-ia64-owner@vger.kernel.org] On Behalf Of Menyhart, Zoltan
> Sent: Monday, June 13, 2005 12:04 PM
> To: linux-ia64@vger.kernel.org
> Subject: Montecito processor family 
> 
> Could someone, please, tell me what the family of the
> Montecito processor will be in /proc/cpuinfo?
> (text representation, numerical ID)
> 
> Thanks,
> 
> Zoltan

---
Takayoshi Kochi

Re: Montecito processor family

[Matthew Wilcox]

On Wed, Nov 09, 2005 at 10:54:45PM +0900, Takayoshi Kochi wrote:
> I see that nothing has happend to Montecito's family name
> in both Linus' and Tony's tree since then.
> 
> Is adding 'Itanium 2' for case 0x20 enough or do we need
> something different?
> 
> Intel people may want to decide what it should be, according to
> their marketing/branding plan ;)

I'm sure they're having trouble getting that patch through Intel legal ;-)

Maybe we could put in a patch temporarily that calls it "Montecito",
then Intel can patch it to whatever the official marketing name is
upon release?

I'm not quite sure why we're so allergic to using the codenames in the
ia64 port.  I mean, look at arch/i386/kernel/cpu/intel.c

Re: Montecito processor family

[Takayoshi Kochi]

Hi,

> > I see that nothing has happend to Montecito's family name
> > in both Linus' and Tony's tree since then.
> > 
> > Is adding 'Itanium 2' for case 0x20 enough or do we need
> > something different?
> > 
> > Intel people may want to decide what it should be, according to
> > their marketing/branding plan ;)
> 
> I'm sure they're having trouble getting that patch through Intel legal ;-)
> 
> Maybe we could put in a patch temporarily that calls it "Montecito",
> then Intel can patch it to whatever the official marketing name is
> upon release?

IIRC the field once was "McKinley" for Itanium2 but later replaced with
"Itanium 2".  So this sounds ok.  But probably as no real application
depends on or relies on the field, I think we can display '32' as it
is until the 'official' name is given.

> I'm not quite sure why we're so allergic to using the codenames in the
> ia64 port.  I mean, look at arch/i386/kernel/cpu/intel.c

Maybe we can add 'codename' field in cpuinfo so that people can
recognize codename:marketing name correspondense, and we can
distinguish McKinley, Madison, Deerfield, ... (I don't remember all)
among Itanium2s ;)

---
Takayoshi Kochi

RE: Montecito processor family

[Luck, Tony]

Digging up this from the distant past (November, 2005): 

> > I see that nothing has happend to Montecito's family name
> > in both Linus' and Tony's tree since then.
> > 
> > Is adding 'Itanium 2' for case 0x20 enough or do we need
> > something different?

Printing "Itanium 2" hides information since that is the
same string as we use for family 0x1f.  So this would make
it hard/impossible for a script reading /proc/cpuinfo to tell
whether the cpu was McKinley/Madison or Montecito.

> > Intel people may want to decide what it should be, according to
> > their marketing/branding plan ;)

It seems that the branding people focus most of their time and
energy on processor implementations, rather than on families of
processors.  So there isn't a clear answer from them on just what
they'd like 0x20 to be tranlated to.  One did suggest:

family   : Dual-core Intel(r) Itanium(r) 2 processor 9000 series

But that rather seriously overflows the "char family[32]" buffer into
which it would need to be copied, doesn't fit into the style of
earlier family names as used by Linux and might be outdated if
we are still using family 0x20 for processors with more than two
cores.

> I'm sure they're having trouble getting that patch through Intel legal ;-)
Marketing is a much tougher sell than legal :-)
 
> Maybe we could put in a patch temporarily that calls it "Montecito",
> then Intel can patch it to whatever the official marketing name is
> upon release?

"Montecito" would be a poor choice.  Next processor in the series is
"Montvale", and it will also have family 0x20.

> IIRC the field once was "McKinley" for Itanium2 but later replaced with
> "Itanium 2".  So this sounds ok.  But probably as no real application
> depends on or relies on the field, I think we can display '32' as it
> is until the 'official' name is given.

32 is good ... it even makes us more like arch/i386/kernel/cpu/proc.c
which makes no attempt to interpret the number, just prints it in decimal.
As a bonus, no patch is needed, nor will any future changes be needed
as new family numbers are assigned!

The only remaining question is whether we should drop the translation
of 0x7 to "Itanium" and 0x1f to "Itanium 2", and just unconditionally
print the family as a decimal number.  This would make it all symetrical
(but sadly requires strong evidence that there are no applications that
depend on the old string values for the "family" field in /proc/cpuinfo).

-Tony

Re: Montecito processor family

[Matthew Wilcox]

On Wed, May 31, 2006 at 05:03:27PM -0700, Luck, Tony wrote:
> Digging up this from the distant past (November, 2005): 
> 
> It seems that the branding people focus most of their time and
> energy on processor implementations, rather than on families of
> processors.  So there isn't a clear answer from them on just what
> they'd like 0x20 to be tranlated to.  One did suggest:
> 
> family   : Dual-core Intel(r) Itanium(r) 2 processor 9000 series
> 
> But that rather seriously overflows the "char family[32]" buffer into
> which it would need to be copied, doesn't fit into the style of
> earlier family names as used by Linux and might be outdated if
> we are still using family 0x20 for processors with more than two
> cores.

And is a bit crass ... I mean we already plug it as a GenuineIntel in
the vendor field.  How about more plainly:

family    : Multi-core Itanium 2

I suppose this risks confusion with HP's Hondo package, though.  Maybe

family    : 9000 series Itanium 2

would do better?

> > Maybe we could put in a patch temporarily that calls it "Montecito",
> > then Intel can patch it to whatever the official marketing name is
> > upon release?
> 
> "Montecito" would be a poor choice.  Next processor in the series is
> "Montvale", and it will also have family 0x20.

I would hope that the family name would be decided before Montvale was
released ;-)

> 32 is good ... it even makes us more like arch/i386/kernel/cpu/proc.c
> which makes no attempt to interpret the number, just prints it in decimal.
> As a bonus, no patch is needed, nor will any future changes be needed
> as new family numbers are assigned!

Yes, I like this idea.  Being More Like i386 is always a good idea.

> The only remaining question is whether we should drop the translation
> of 0x7 to "Itanium" and 0x1f to "Itanium 2", and just unconditionally
> print the family as a decimal number.  This would make it all symetrical
> (but sadly requires strong evidence that there are no applications that
> depend on the old string values for the "family" field in /proc/cpuinfo).

We've always felt free to change these strings before.  Anyone relying
on them for anything more than display-to-the-user purposes is on a
losing streak.

Re: Montecito processor family

[Russ Anderson]

Tony Luck wrote:
> 
> Digging up this from the distant past (November, 2005): 
> 
> > > I see that nothing has happend to Montecito's family name
> > > in both Linus' and Tony's tree since then.
> > > 
> > > Is adding 'Itanium 2' for case 0x20 enough or do we need
> > > something different?
> 
> Printing "Itanium 2" hides information since that is the
> same string as we use for family 0x1f.  So this would make
> it hard/impossible for a script reading /proc/cpuinfo to tell
> whether the cpu was McKinley/Madison or Montecito.

Why not have "model name" with the text name, like on ia32?

vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      : Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping        : 1

> > > Intel people may want to decide what it should be, according to
> > > their marketing/branding plan ;)
> 
> It seems that the branding people focus most of their time and
> energy on processor implementations, rather than on families of
> processors.  So there isn't a clear answer from them on just what
> they'd like 0x20 to be tranlated to.  One did suggest:
> 
> family   : Dual-core Intel(r) Itanium(r) 2 processor 9000 series

That's almost as bad as "Intel(R) Pentium(R) 4 CPU 2.80GHz".

I like the "Pentium III (Coppermine)" style, based on family
and model.  "Itanium 2 (Madison)" and "Itanium 2 (Montecito)" would
be consistent with that style.  

> > Maybe we could put in a patch temporarily that calls it "Montecito",
> > then Intel can patch it to whatever the official marketing name is
> > upon release?
> 
> "Montecito" would be a poor choice.  Next processor in the series is
> "Montvale", and it will also have family 0x20.

That's why a combination of family and model is needed.

> > IIRC the field once was "McKinley" for Itanium2 but later replaced with
> > "Itanium 2".  So this sounds ok.  But probably as no real application
> > depends on or relies on the field, I think we can display '32' as it
> > is until the 'official' name is given.
> 
> 32 is good ... it even makes us more like arch/i386/kernel/cpu/proc.c
> which makes no attempt to interpret the number, just prints it in decimal.
> As a bonus, no patch is needed, nor will any future changes be needed
> as new family numbers are assigned!

It would be nice to have a "model name" text description,
for people that don't know the meaning of 32.  There are
people that need to use the right flavor of CPU that know
the English name.  It's easier to have the code print the
text name than teach them the cryptic numbers.

-- 
Russ Anderson, OS RAS/Partitioning Project Lead  
SGI - Silicon Graphics Inc          rja@sgi.com

Re: Montecito processor family

[Alex Williamson]

On Wed, 2006-05-31 at 22:06 -0500, Russ Anderson wrote:
> It would be nice to have a "model name" text description,
> for people that don't know the meaning of 32.  There are
> people that need to use the right flavor of CPU that know
> the English name.  It's easier to have the code print the
> text name than teach them the cryptic numbers.

  I second this.  It shouldn't be as hard as it currently is to
determine what processor is installed in the system.  The common names
are well enough advertised, even if unofficial.  The family/model
numbers don't mean much to most people.  Thanks,

	Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.

RE: Montecito processor family

[Luck, Tony]

> Why not have "model name" with the text name, like on ia32?
> 
> vendor_id       : GenuineIntel
> cpu family      : 15
> model           : 4
> model name      : Intel(R) Pentium(R) 4 CPU 2.80GHz
> stepping        : 1

This sounds like an excellent plan.  We can even use the new
(in SDM2.2 p. 2:345) PAL_BRAND_INFO call to get the right
(Intel marketting/legal approved) string.  For older systems
that don't implement PAL_BRAND_INFO we could have some fallback
code that decodes family/model to Merced/McKinley/Madison.

-Tony

Re: Montecito processor family

[dann frazier]

On Wed, May 31, 2006 at 07:20:17PM -0600, Matthew Wilcox wrote:
> We've always felt free to change these strings before.  Anyone relying
> on them for anything more than display-to-the-user purposes is on a
> losing streak.

Debian Installer uses it for determining the best kernel to install -
is there a better way?  Of course, old installers aren't expected to
work with new kernels, so the change won't hurt us as long as someone
notices the change.

-- 
dann frazier | HP Open Source and Linux Organization

Re: Montecito processor family

[Russ Anderson]

dann frazier wrote:
> 
> On Wed, May 31, 2006 at 07:20:17PM -0600, Matthew Wilcox wrote:
> > We've always felt free to change these strings before.  Anyone relying
> > on them for anything more than display-to-the-user purposes is on a
> > losing streak.
> 
> Debian Installer uses it for determining the best kernel to install -
> is there a better way?  Of course, old installers aren't expected to
> work with new kernels, so the change won't hurt us as long as someone
> notices the change.

That seems like a good reason for family and model to be
numbers straight from the hardware.  Applications can key
off the numbers.  Then the text "model name" string could 
change without breaking applications.

vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      : Intel(R) Pentium(R) 4 CPU 2.80GHz
stepping        : 1


-- 
Russ Anderson, OS RAS/Partitioning Project Lead  
SGI - Silicon Graphics Inc          rja@sgi.com

RE: Montecito processor family

[Luck, Tony]

> That seems like a good reason for family and model to be
> numbers straight from the hardware.  Applications can key
> off the numbers.  Then the text "model name" string could 
> change without breaking applications.
> 
> vendor_id       : GenuineIntel
> cpu family      : 15
> model           : 4
> model name      : Intel(R) Pentium(R) 4 CPU 2.80GHz
> stepping        : 1

Using PAL_BRAND_INFO on Montecito I end up with this:

vendor     : GenuineIntel
arch       : IA-64
family     : 32
model      : 0
model name : Intel(r) Itanium(r) 2 Processor 1.6GHz with 24M L3 Cache for 533MHz Platforms

Which is stylistically pretty similar (though somewhat more verbose
... PAL_BRAND_INFO allows for up to 127 characters + NUL so it could
get even chattier, but at least there is an upper bound).

-Tony

Re: Montecito processor family

[David Mosberger-Tang]

On 6/3/06, Luck, Tony <tony.luck@intel.com> wrote:

> model name : Intel(r) Itanium(r) 2 Processor 1.6GHz with 24M L3 Cache for 533MHz Platforms

Presumably this would be the same string that's used in the processor
manuals?  If so, that would be really helpful to have.

  --david
-- 
Mosberger Consulting LLC, http://www.mosberger-consulting.com/

RE: Montecito processor family

[Luck, Tony]

> > model name : Intel(r) Itanium(r) 2 Processor 1.6GHz with 24M L3 Cache for 533MHz Platforms
>
> Presumably this would be the same string that's used in the processor
> manuals?  If so, that would be really helpful to have.

The same person at Intel provides the string to the PAL team for the
PAL_BRAND_INFO call as gets used in the manuals.  So the goal is that
they should be the same.  But the reaction time of print-media and
PAL releases is different, so when branding changes happen, the strings
may get out of sync.  That's apparently the case here: print manuals
will include the 9xxx processor model number, but current PAL doesn't
have that.

-Tony

RE: Montecito processor family

[Chen, Kenneth W]

Luck, Tony wrote on Thursday, June 01, 2006 9:33 AM
> > Why not have "model name" with the text name, like on ia32?
> > 
> > vendor_id       : GenuineIntel
> > cpu family      : 15
> > model           : 4
> > model name      : Intel(R) Pentium(R) 4 CPU 2.80GHz
> > stepping        : 1
> 
> This sounds like an excellent plan.  We can even use the new
> (in SDM2.2 p. 2:345) PAL_BRAND_INFO call to get the right
> (Intel marketting/legal approved) string.  For older systems
> that don't implement PAL_BRAND_INFO we could have some fallback
> code that decodes family/model to Merced/McKinley/Madison.


I would also like to take this opportunity to revamp feature string.
It is way too long, and should be either two or three letter acronym
like x86:

X86 feature string: "flags : fpu vme de pse tsc msr pae mce ... "

- features   : branchlong, 16-byte atomic ops
+ features   : lb ao

RE: Montecito processor family

[Alex Williamson]

On Tue, 2006-06-06 at 11:04 -0700, Chen, Kenneth W wrote:
> 
> I would also like to take this opportunity to revamp feature string.
> It is way too long, and should be either two or three letter acronym
> like x86:
> 
> X86 feature string: "flags : fpu vme de pse tsc msr pae mce ... "
> 
> - features   : branchlong, 16-byte atomic ops
> + features   : lb ao

   On the down side, I find that I sometimes have to go look in the code
to figure out which flags I care about on x86.  Are "lb" and "ao"
defined somewhere?

	Alex

-- 
Alex Williamson                             HP Open Source & Linux Org.

RE: Montecito processor family

[Chen, Kenneth W]

Alex Williamson wrote on Tuesday, June 06, 2006 11:17 AM
> On Tue, 2006-06-06 at 11:04 -0700, Chen, Kenneth W wrote:
> > 
> > I would also like to take this opportunity to revamp feature string.
> > It is way too long, and should be either two or three letter acronym
> > like x86:
> > 
> > X86 feature string: "flags : fpu vme de pse tsc msr pae mce ... "
> > 
> > - features   : branchlong, 16-byte atomic ops
> > + features   : lb ao
> 
>    On the down side, I find that I sometimes have to go look in the
> code to figure out which flags I care about on x86.  Are "lb" and "ao"
> defined somewhere?


I thought the x86 acronym was taken straight out of SDM, refer to CPUID
instruction detail there. We should do the same on ia64.

Section 3.1.11 out of SDM volume 1:

field bit description
lb    0   long branch (brl) instructions.
sd    1   spontaneous deferral
ao    2   16-byte atomic operations
rv    63:3 Reserved.


It's only my wishful thinking. The acronym should be improved a bit to
be more creative and meaningful in its current form.  Oh well.

Re: Montecito processor family

[Jes Sorensen]

>>>>> "Ken" = Chen, Kenneth W <kenneth.w.chen@intel.com> writes:

Ken> I thought the x86 acronym was taken straight out of SDM, refer to
Ken> CPUID instruction detail there. We should do the same on ia64.

Ken> Section 3.1.11 out of SDM volume 1:

Ken> field bit description lb 0 long branch (brl) instructions.  sd 1
Ken> spontaneous deferral ao 2 16-byte atomic operations rv 63:3
Ken> Reserved.

Ken> It's only my wishful thinking. The acronym should be improved a
Ken> bit to be more creative and meaningful in its current form.  Oh
Ken> well.

IMHO single words are much nicer to read than strange letter
combos. If we take this path, could we at least make sure it gets
documented in Documentation/ somewhere?

Thanks,
Jes