cacheline size detection code in 2.5.66

cacheline size detection code in 2.5.66

[Andi Kleen]

Hi,

You added this code in 2.5.66: 

+       /*
+        * Assume PCI cacheline size of 32 bytes for all x86s except K7/K8
+        * and P4. It's also good for 386/486s (which actually have 16)
+        * as quite a few PCI devices do not support smaller values.
+        */
+        pci_cache_line_size = 32 >> 2;
+       if (c->x86 >= 6 && c->x86_vendor == X86_VENDOR_AMD)
+               pci_cache_line_size = 64 >> 2;  /* K7 & K8 */
+       else if (c->x86 > 6)
+               pci_cache_line_size = 128 >> 2; /* P4 */

This will be wrong on Pentium M for example which has a 32byte cache
line but x86 model 9. But it's actually not needed, because all the 
new CPUs report their cacheline size as part of CPUID for CLFLUSH.

When the CPU supports CLFLUSH you can just extract it from 
the second byte in the second word reported by CPUID 1.
With that just use what the CPU tells you. This should also
work correctly on VIA etc which afaik support CLFLUSH 
in the newer CPUs.

The x86-64 port extract it like this in setup.c:
	if (c->x86_capability[0] & (1<<19)) 
       		c->x86_clflush_size = ((misc >> 8) & 0xff) * 8;
	}. 
I changed its pci code to use that directly now. i386 likely
should too. When no CLFLUSH is supported you can safely assume 32byte
cachelines.

-Andi

	

Re: cacheline size detection code in 2.5.66

[Ivan Kokshaysky]

On Tue, Mar 25, 2003 at 08:15:32AM +0100, Andi Kleen wrote:
> This will be wrong on Pentium M for example which has a 32byte cache
> line but x86 model 9. But it's actually not needed, because all the 
> new CPUs report their cacheline size as part of CPUID for CLFLUSH.

We check x86 family, not model. According to Intel docs Pentium M
has family code 6.

> The x86-64 port extract it like this in setup.c:
> 	if (c->x86_capability[0] & (1<<19)) 
>        		c->x86_clflush_size = ((misc >> 8) & 0xff) * 8;
> 	}. 
> I changed its pci code to use that directly now. i386 likely
> should too. When no CLFLUSH is supported you can safely assume 32byte
> cachelines.

Apparently it's fine for K8, but what about Athlons? They have
bit 19 == 0 and 64-byte cache lines.
BTW, the "AMD Processor Recognition Application Note" calls bit 19
"Multiprocessing Capable". ;-)

Ivan.

Re: cacheline size detection code in 2.5.66

[Dave Jones]

On Tue, Mar 25, 2003 at 08:15:32AM +0100, Andi Kleen wrote:

 > +        pci_cache_line_size = 32 >> 2;
 > +       if (c->x86 >= 6 && c->x86_vendor == X86_VENDOR_AMD)
 > +               pci_cache_line_size = 64 >> 2;  /* K7 & K8 */
 > +       else if (c->x86 > 6)
 > +               pci_cache_line_size = 128 >> 2; /* P4 */
 > 
 > This will be wrong on Pentium M for example which has a 32byte cache
 > line but x86 model 9.

The above test is comparing family, not model.  It's my understanding
that it's still a family 6 CPU, so it'll match '32'.

 > But it's actually not needed, because all the 
 > new CPUs report their cacheline size as part of CPUID for CLFLUSH.
 > When the CPU supports CLFLUSH you can just extract it from 
 > the second byte in the second word reported by CPUID 1.
 > With that just use what the CPU tells you. This should also
 > work correctly on VIA etc which afaik support CLFLUSH 
 > in the newer CPUs.

Nope. Nehemiah :-
flags		: fpu de pse tsc msr cx8 mtrr pge cmov mmx fxsr sse

Cache line size is still available from cpuid 80000006 though,
but as this is vendor and model specific, this could get messy
to decode. And then there's errata...

		Dave

Re: cacheline size detection code in 2.5.66

[Andi Kleen]

On Tue, Mar 25, 2003 at 12:33:10PM +0100, Ivan Kokshaysky wrote:
> > The x86-64 port extract it like this in setup.c:
> > 	if (c->x86_capability[0] & (1<<19)) 
> >        		c->x86_clflush_size = ((misc >> 8) & 0xff) * 8;
> > 	}. 
> > I changed its pci code to use that directly now. i386 likely
> > should too. When no CLFLUSH is supported you can safely assume 32byte
> > cachelines.
> 
> Apparently it's fine for K8, but what about Athlons? They have
> bit 19 == 0 and 64-byte cache lines.

Ok.

Athlon likely reports its cacheline size too in 8000_0005 / ECX (I think,
not checked), but it doesn't have the CLFLUSH bit, you're right. 


> BTW, the "AMD Processor Recognition Application Note" calls bit 19
> "Multiprocessing Capable". ;-)

Hmm, yes it's broken. 19 is CFLUSH in the 8000_0001 extended CPUID word,
but not in index 0000_0001. Copied wrong from cpufeature.h.

Probably it should reinitialize x86_capability[0] from 80000001 when
available, but need to double check the list.

Broken in i386 too.

-Andi

Re: cacheline size detection code in 2.5.66

[Dave Jones]

On Tue, Mar 25, 2003 at 01:15:27PM +0100, Andi Kleen wrote:

 > > BTW, the "AMD Processor Recognition Application Note" calls bit 19
 > > "Multiprocessing Capable". ;-)
 > Hmm, yes it's broken. 19 is CFLUSH in the 8000_0001 extended CPUID word,
 > but not in index 0000_0001.

On K8 maybe, but on K7, its correct as it stands. bit 19 of 80000001
is the MP capability bit. As K7 never had clflush, its not defined
there.

 > Broken in i386 too.

I don't see anything broken there. The K7 / K8 feature flags are not
bit for bit compatible though iirc (can't find my K8 cpuid manuals right now).

		Dave

Re: cacheline size detection code in 2.5.66

[Andi Kleen]

>  > Broken in i386 too.
> 
> I don't see anything broken there. The K7 / K8 feature flags are not
> bit for bit compatible though iirc (can't find my K8 cpuid manuals right now).

Umm - they should be. Otherwise CPUID would be completely useless.

I double checked both the Intel and the x86-64 manual now and bit 19 
of 0000_0001 is CLFLUSH 

So cpufeature.h and the x86-64 test is correct

0000_0001 is supposed to be globally compatible. 8000_0001 
is supposed to be compatible inside AMD CPUs (and 19 is reserved here)

Ivan confused me.  Either he read the application note wrong or it is wrong.

-Andi

Re: cacheline size detection code in 2.5.66

[Ivan Kokshaysky]

On Tue, Mar 25, 2003 at 02:35:25PM +0100, Andi Kleen wrote:
> Ivan confused me.  Either he read the application note wrong or it is wrong.

Ok, it's available at
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/20734.pdf

Ivan.

Re: cacheline size detection code in 2.5.66

[Dave Jones]

On Tue, Mar 25, 2003 at 05:39:37PM +0300, Ivan Kokshaysky wrote:
 > On Tue, Mar 25, 2003 at 02:35:25PM +0100, Andi Kleen wrote:
 > > Ivan confused me.  Either he read the application note wrong or it is wrong.
 > 
 > Ok, it's available at
 > http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/20734.pdf
 
For info, that is a reliable[*] way to detect XP/MP Athlons.
It's used in the kernel for SMP tainting, and x86info has also been
using it for some time.

		Dave

[*] AMD screwed up one stepping of XPs and enabled the MP bit even though
    they weren't actually MPs.