[v2,RFC] parisc: Change L1_CACHE_BYTES to 16
diff mbox

Message ID 32A3BF6F-B243-4AD4-9AE9-A5F9DAE0270A@bell.net
State New
Headers show

Commit Message

John David Anglin Sept. 27, 2015, 4:07 p.m. UTC
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.

Signed-off-by: John David Anglin <dave.anglin@bell.net>

--
John David Anglin	dave.anglin@bell.net

Comments

James Bottomley Sept. 27, 2015, 4:17 p.m. UTC | #1
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
John David Anglin Sept. 27, 2015, 4:46 p.m. UTC | #2
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

Patch
diff mbox

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