Re: [PATCH v2 2/3] x86/cpu: Add new Intel Atom CPU model name

[Luck, Tony]

On Tue, Aug 20, 2019 at 04:57:35PM +0200, Peter Zijlstra wrote:
> On Tue, Aug 20, 2019 at 12:48:05PM +0000, Luck, Tony wrote:
> > 
> > >> +#define INTEL_FAM6_ATOM_AIRMONT_NP    0x75 /* Lightning Mountain */
> > > 
> > > What's _NP ?
> > 
> > Network Processor. But that is too narrow a descriptor. This is going to be used in
> > other areas besides networking. 
> > 
> > Iâm contemplating calling it AIRMONT2
> 
> What would describe the special sause that warranted a new SOC? If this
> thing is marketed as 'Network Processor' then I suppose we can actually
> use it, esp. if we're going to see this more, like the MID thing -- that
> lived for a while over multiple uarchs.

The reasons for allocating a new model number are a mystery.
I've seen cases where I thought we'd get a new numnber for sure,
but then just bumped the stepping. I've also seen us allocate a
new number when it didn't look needed (to me, from my OS perspective).

As I mentioned above, there are some folks internally that think
NP == Network Processor is too narrow a pigeonhole for this CPU.

But _NPAOS (Network Processor And Other Stuff) doesn't sound helpful.

> Note that for the big cores we added the NNPI thing, which was for
> Neural Network Processing something.

I'm sure that we will invent all sorts of strings for the "OPTDIFF"
part of the name (many of which will only be used once or twice).

Rationale for "AIRMONT2" is that this is derived from Airmont. So
you'd expect many model specific bits of code to do the same for
this as they did for plain AIRMONT. But in a few corner cases there
will be separate code.

Perhaps I need to update the rubric that I just added to the
head on intel-family.h to say that the MICROARCH element may
be followed by an optional number to differentiate SOCs that
use essentially the same core, but have different model numbers
because of SOC differences outside of the core.

-Tony