| Message ID | 32A3BF6F-B243-4AD4-9AE9-A5F9DAE0270A@bell.net (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
On Sun, 2015-09-27 at 12:07 -0400, John David Anglin wrote: > On 2015-09-26, at 11:38 AM, John David Anglin wrote: > > > The attached change reduces L1_CACHE_BYTES from 32 on PA1.1 and 64 on PA2.0 to 16. > > > > This is based on examination of the L1 cache design for the PA-8700 processor where it can > > be seen the processor loads two double words per cycle. This line length is consistent with the > > original alignment requirement for the ldcw instruction. > > > > Thus, we need to distinguish between the L1 and L2 (SMP) cache line lengths. > > > > The attached change bumps SMP_CACHE_BYTES to 128 bytes as this is the line length used > > on PA-8800 and PA-8900 processors. This increases the overall kernel size somewhat but seems > > logically correct. > > > Slight tweak to previous. This version only bumps SMP_CACHE_BYTES when CONFIG_SMP > is defined. What makes you think we need SMP_CACHE_BYTES to be different from L1_CACHE_BYTES? No other architecture does this. The theory that gives us two defines was that some SMP systems would arbitrate for memory at geater than cache line offsets but, in practise, none does because that's the level at which the cross CPU memory ownership model works anyway. James -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2015-09-27, at 12:17 PM, James Bottomley wrote: > What makes you think we need SMP_CACHE_BYTES to be different from > L1_CACHE_BYTES? No other architecture does this. The theory that gives > us two defines was that some SMP systems would arbitrate for memory at > geater than cache line offsets but, in practise, none does because > that's the level at which the cross CPU memory ownership model works > anyway. I was just keeping the values we had before. Changing to the new L1_CACHE_BYTES value probably needs testing. Dave -- John David Anglin dave.anglin@bell.net -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/parisc/include/asm/cache.h b/arch/parisc/include/asm/cache.h index 47f11c7..cf11dd4 100644 --- a/arch/parisc/include/asm/cache.h +++ b/arch/parisc/include/asm/cache.h @@ -7,24 +7,27 @@ /* - * PA 2.0 processors have 64-byte cachelines; PA 1.1 processors have - * 32-byte cachelines. The default configuration is not for SMP anyway, + * PA 2.0 processors have 64 and 128-byte L2 cachelines; PA 1.1 processors + * have 32-byte cachelines. The default configuration is not for SMP anyway, * so if you're building for SMP, you should select the appropriate * processor type. There is a potential livelock danger when running * a machine with this value set too small, but it's more probable you'll * just ruin performance. */ -#ifdef CONFIG_PA20 -#define L1_CACHE_BYTES 64 -#define L1_CACHE_SHIFT 6 -#else -#define L1_CACHE_BYTES 32 -#define L1_CACHE_SHIFT 5 -#endif +#define L1_CACHE_BYTES 16 +#define L1_CACHE_SHIFT 4 #ifndef __ASSEMBLY__ +#ifdef CONFIG_SMP +#ifdef CONFIG_PA20 +#define SMP_CACHE_BYTES (8 * L1_CACHE_BYTES) +#else +#define SMP_CACHE_BYTES (2 * L1_CACHE_BYTES) +#endif +#else #define SMP_CACHE_BYTES L1_CACHE_BYTES +#endif #define ARCH_DMA_MINALIGN L1_CACHE_BYTES