From: Zoltan Menyhart <Zoltan.Menyhart@bull.net>
To: linux-ia64@vger.kernel.org
Subject: Re: flush_icache_range
Date: Fri, 20 May 2005 14:17:51 +0000 [thread overview]
Message-ID: <428DF18F.8040600@bull.net> (raw)
In-Reply-To: <4236D7B5.8050408@bull.net>
[-- Attachment #1: Type: text/plain, Size: 1383 bytes --]
Here is a small patch that flushes the i-cache 64 bytes
by 64 bytes on Itanium 2 (or +).
Some measures on a Tiger box with the indicated CPU-s:
processor : 0
vendor : GenuineIntel
arch : IA-64
family : Itanium 2
model : 1
revision : 5
archrev : 0
features : branchlong
cpu number : 0
cpu regs : 4
cpu MHz : 1296.439995
itc MHz : 1296.439995
BogoMIPS : 1941.96
etc...
Flushing a page of 64 Kbytes (the others do not do anything,
they have not got anything about my data on their caches):
With a 32-byte stride:
Modified in d-cache: cycles = 215 K, time = 169 usec
Valid: cycles = 222 K, time = 171 usec
Invalid: cycles = 222 K, time = 171 usec
Note that for the dirty case, only the 1st flush causes a write-
back from the L2 / L3 caches, the 3 other flushes find the cache
entries invalid in the L2 / L3 caches.
With a 64-byte stride:
Modified in d-cache: cycles = 63 K, time = 49 usec
Valid: cycles = 116 K, time = 89 usec
Invalid: cycles = 116 K, time = 89 usec
It is funny to see that the dirty lines can be flushed more
efficiently. I guess the CPU knows in such a case that the others
cannot have anything to flush, the flush request may not even be
issued to the other CPU-s.
I also tried to issue more than one flush per loop-body
iteration, it did not help.
Thanks,
Zoltan
[-- Attachment #2: diff --]
[-- Type: text/plain, Size: 1280 bytes --]
diff -Nru linux-2.6.11-old/arch/ia64/lib/flush.S linux-2.6.11/arch/ia64/lib/flush.S
--- linux-2.6.11-old/arch/ia64/lib/flush.S 2005-05-20 15:26:18.330498876 +0200
+++ linux-2.6.11/arch/ia64/lib/flush.S 2005-05-20 15:28:25.639091067 +0200
@@ -7,6 +7,23 @@
#include <asm/asmmacro.h>
#include <asm/page.h>
+
+/*
+ * Note that "L1_CACHE_SHIFT" and "L1_CACHE_BYTES" defined in
+ * include/asm-ia64/cache.h are not what their names suggest.
+ * They actually defines the cache line size for L2.
+ *
+ * We have to flush the L1 i-cache, too.
+ */
+#if defined(CONFIG_ITANIUM)
+#define L1_CACHE_SHIFT 5
+#else
+#define L1_CACHE_SHIFT 6
+#endif
+
+#define L1_CACHE_BYTES (1 << L1_CACHE_SHIFT)
+
+
/*
* flush_icache_range(start,end)
* Must flush range from start to end-1 but nothing else (need to
@@ -17,7 +34,7 @@
alloc r2=ar.pfs,2,0,0,0
sub r8=in1,in0,1
;;
- shr.u r8=r8,5 // we flush 32 bytes per iteration
+ shr.u r8=r8,L1_CACHE_SHIFT // we flush L1_CACHE_BYTES bytes per iteration
.save ar.lc, r3
mov r3=ar.lc // save ar.lc
;;
@@ -26,8 +43,12 @@
mov ar.lc=r8
;;
+#if defined(CONFIG_ITANIUM)
.Loop: fc in0 // issuable on M0 only
- add in0=32,in0
+#else
+.Loop: fc.i in0
+#endif
+ add in0=L1_CACHE_BYTES,in0
br.cloop.sptk.few .Loop
;;
sync.i
next prev parent reply other threads:[~2005-05-20 14:17 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-15 12:40 flush_icache_range Zoltan Menyhart
2005-03-15 18:21 ` flush_icache_range David Mosberger
2005-03-16 10:58 ` flush_icache_range Zoltan Menyhart
2005-03-16 11:19 ` flush_icache_range Duraid Madina
2005-03-16 18:31 ` flush_icache_range David Mosberger
2005-05-20 14:17 ` Zoltan Menyhart [this message]
2005-05-20 15:03 ` flush_icache_range David Mosberger
2005-05-23 13:43 ` flush_icache_range Zoltan Menyhart
2005-05-26 17:21 ` flush_icache_range David Mosberger
2005-05-26 17:39 ` flush_icache_range Seth, Rohit
2005-05-27 15:45 ` flush_icache_range Zoltan Menyhart
2005-05-27 15:56 ` flush_icache_range David Mosberger
2005-05-27 16:45 ` flush_icache_range Zoltan Menyhart
2005-05-27 16:55 ` flush_icache_range David Mosberger
2005-05-27 18:27 ` flush_icache_range Grant Grundler
2005-05-27 19:00 ` flush_icache_range Russ Anderson
2005-05-29 20:23 ` flush_icache_range Menyhart, Zoltan
2005-06-01 23:50 ` flush_icache_range David Mosberger
2005-06-02 3:00 ` flush_icache_range Jim Hull
2005-06-02 12:12 ` flush_icache_range Zoltan Menyhart
2005-06-02 14:25 ` flush_icache_range Zoltan Menyhart
2005-06-02 17:36 ` flush_icache_range David Mosberger
2005-06-02 18:28 ` flush_icache_range David Mosberger
2005-06-02 18:31 ` flush_icache_range David Mosberger
2005-06-02 19:00 ` flush_icache_range Jim Hull
2005-06-02 21:37 ` flush_icache_range Menyhart, Zoltan
2005-06-02 22:23 ` flush_icache_range David Mosberger
2005-06-02 22:55 ` flush_icache_range Menyhart, Zoltan
2005-06-02 23:07 ` flush_icache_range David Mosberger
2005-06-03 12:35 ` flush_icache_range Zoltan Menyhart
2005-06-03 21:09 ` flush_icache_range David Mosberger
2005-06-13 11:20 ` flush_icache_range Zoltan Menyhart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=428DF18F.8040600@bull.net \
--to=zoltan.menyhart@bull.net \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox