From: David Gibson <david@gibson.dropbear.id.au>
To: Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>
Cc: Anton Blanchard <anton@samba.org>,
linux-kernel@vger.kernel.org, linuxppc64-dev@lists.linuxppc.org
Subject: [PPC64] Use slbie, not slbia in hugepage code
Date: Tue, 4 May 2004 20:08:00 +1000 [thread overview]
Message-ID: <20040504100800.GK21024@zax> (raw)
Linus, please apply:
On PPC64, when we prepare segments below 4G for use with hugepages, we
need to flush their entries from the SLB, in case SLB entries
specifying normal pages were already present.
Previously we did that by flushing the entire SLB, the patch below
changes this to individually flush each necessary segment with slbie.
The new version may well be slightly faster, but the real reason for
it is so that this code path doesn't need to be changed to reinstate
any bolted SLB entries, if we add them. The existing version has
already caused problems (read, crashes) when combined with some
patches that add bolted SLB entries.
Index: working-2.6/arch/ppc64/mm/hugetlbpage.c
===================================================================
--- working-2.6.orig/arch/ppc64/mm/hugetlbpage.c 2004-05-04 16:35:55.000000000 +1000
+++ working-2.6/arch/ppc64/mm/hugetlbpage.c 2004-05-04 20:07:00.023964800 +1000
@@ -245,9 +245,20 @@
return 0;
}
-static void do_slbia(void *unused)
+static void flush_segments(void *parm)
{
- asm volatile ("isync; slbia; isync":::"memory");
+ u16 segs = (unsigned long) parm;
+ unsigned long i;
+
+ asm volatile("isync" : : : "memory");
+
+ for (i = 0; i < 16; i++) {
+ if (! (segs & (1U << i)))
+ continue;
+ asm volatile("slbie %0" : : "r" (i << SID_SHIFT));
+ }
+
+ asm volatile("isync" : : : "memory");
}
static int prepare_low_seg_for_htlb(struct mm_struct *mm, unsigned long seg)
@@ -316,10 +327,10 @@
return -EBUSY;
mm->context.htlb_segs |= newsegs;
- /* the context change must make it to memory before the slbia,
+ /* the context change must make it to memory before the flush,
* so that further SLB misses do the right thing. */
mb();
- on_each_cpu(do_slbia, NULL, 0, 1);
+ on_each_cpu(flush_segments, (void *)(unsigned long)newsegs, 0, 1);
return 0;
}
--
David Gibson | For every complex problem there is a
david AT gibson.dropbear.id.au | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
reply other threads:[~2004-05-04 10:12 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20040504100800.GK21024@zax \
--to=david@gibson.dropbear.id.au \
--cc=akpm@osdl.org \
--cc=anton@samba.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc64-dev@lists.linuxppc.org \
--cc=torvalds@osdl.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