[Mono-dev] [PATCH]: Improve sparc I-cache flushing under Linux.

David Miller davem at davemloft.net
Sat Nov 3 19:21:16 EDT 2007


On every UltraSPARC chip, it is sufficient to only flush
every 32-byte cache line.

As a future enhancement, if Niagara cpus are detected we can only
perform one flush instruction.  On Niagara the flush address is
completely ignored and the flush is only needed to synchronize the cpu
pipeline with previous stores.

I left the Solaris code as it is, calling sync_instruction_memory().
However, disassembling a test program shows that Solaris does not
optimize it properly and flushes every 8 bytes like the old code here
did.

I think it would be safe to have the Solaris case use the same code as
Linux so that both sides would get the performance improvement.

2007-11-03  David S. Miller  <davem at huronp11.davemloft.net>

	* mini-sparc.c (mono_arch_flush_icache): Make more efficient
	under Linux.  We only need to flush every 32-byte cache line.

Index: mono/mini/mini-sparc.c
===================================================================
--- mono/mini/mini-sparc.c	(revision 88629)
+++ mono/mini/mini-sparc.c	(working copy)
@@ -293,18 +293,28 @@ mono_arch_flush_icache (guint8 *code, gi
 	/* Hopefully this is optimized based on the actual CPU */
 	sync_instruction_memory (code, size);
 #else
-	guint64 *p = (guint64*)code;
-	guint64 *end = (guint64*)(code + ((size + 8) /8));
-
-	/* 
-	 * FIXME: Flushing code in dword chunks in _slow_.
+	gulong start = (gulong) code;
+	gulong end = start + size;
+	gulong align;
+
+	/* Sparcv9 chips only need flushes on 32 byte
+	 * cacheline boundaries.
+	 *
+	 * Sparcv8 needs a flush every 8 bytes.
 	 */
-	while (p < end)
+	align = (sparcv9 ? 32 : 8);
+
+	start &= ~(align - 1);
+	end = (end + (align - 1)) & ~(align - 1);
+
+	while (start < end) {
 #ifdef __GNUC__
-		__asm__ __volatile__ ("iflush %0"::"r"(p++));
+		__asm__ __volatile__ ("iflush %0"::"r"(start));
 #else
-			flushi (p ++);
+		flushi (start);
 #endif
+		start += align;
+	}
 #endif
 }
 




More information about the Mono-devel-list mailing list