| Message ID | 1258195348-2861-5-git-send-email-Joakim.Tjernlund@transmode.se (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Nov 14, 2009, at 2:42 AM, Joakim Tjernlund wrote: > ..... Avoid this by always pinning > kernel instruction TLB space. You may as well map the data space, too, since you have reserved the entries. Take advantage of that performance. Also, some processor variants have very few TLB entries, and may only reserve two entries (although the flag says reserve 4). Ensure there are sufficient resources to do what you want. This is the reason the option is configurable. Thanks. -- Dan
Dan Malek <dan@embeddedalley.com> wrote on 14/11/2009 19:08:43: > On Nov 14, 2009, at 2:42 AM, Joakim Tjernlund wrote: > > > ..... Avoid this by always pinning > > kernel instruction TLB space. > > You may as well map the data space, too, since you have > reserved the entries. Take advantage of that performance. > Also, some processor variants have very few TLB entries, > and may only reserve two entries (although the flag says > reserve 4). Ensure there are sufficient resources to do > what you want. This is the reason the option is configurable. Scott had some concerns about pinning the data space too. That is is why I left the data TLB pinning behind the the config option. How to make better use of the remaining ITLB slots is tricky. Somehow one would want to map at lest one to modules but I cannot see how. Jocke
On Sat, 2009-11-14 at 20:08 +0100, Joakim Tjernlund wrote: > Dan Malek <dan@embeddedalley.com> wrote on 14/11/2009 19:08:43: > > On Nov 14, 2009, at 2:42 AM, Joakim Tjernlund wrote: > > > > > ..... Avoid this by always pinning > > > kernel instruction TLB space. > > > > You may as well map the data space, too, since you have > > reserved the entries. Take advantage of that performance. > > Also, some processor variants have very few TLB entries, > > and may only reserve two entries (although the flag says > > reserve 4). Ensure there are sufficient resources to do > > what you want. This is the reason the option is configurable. > > Scott had some concerns about pinning the data space too. That is > is why I left the data TLB pinning behind the the config option. > > How to make better use of the remaining ITLB slots is tricky. > Somehow one would want to map at lest one to modules but I cannot see how. No. If you use modules, you pay the price. Sane embedded solutions running in "tight" environments don't use modules :-) No point pinning TLB entries on the vmalloc space, really. What -might- be more useful is to look at Grant work on re-doing the early ioremap and providing a way to provide what the old io_block_mapping() did, but with dynamically chosen virtual addresses, to have a pinned entry covering most common IOs. Cheers, Ben.
> > How to make better use of the remaining ITLB slots is tricky. > > Somehow one would want to map at lest one to modules but I cannot see how. > > No. If you use modules, you pay the price. Sane embedded solutions > running in "tight" environments don't use modules :-) No point pinning > TLB entries on the vmalloc space, really. Long ago (2.4 days I think) when using modules on ppc 4xx we hacked the module_alloc function (or whatever it was called back then) to allocate space in the kernel pinned TLB instead of using vmalloc. Gave something like a 2x speedup for module code, since the 4xx TLB is so small and the miss handling is so expensive. I assume it should still be possible to do a similar hack with current kernels. - R.
> > Dan Malek <dan@embeddedalley.com> wrote on 14/11/2009 19:08:43: > > On Nov 14, 2009, at 2:42 AM, Joakim Tjernlund wrote: > > > > > ..... Avoid this by always pinning > > > kernel instruction TLB space. > > > > You may as well map the data space, too, since you have > > reserved the entries. Take advantage of that performance. Just to be clear, I don't reserve and DTLB entries(I think). That remains under the config flag. > > Also, some processor variants have very few TLB entries, > > and may only reserve two entries (although the flag says > > reserve 4). Ensure there are sufficient resources to do > > what you want. This is the reason the option is configurable. > > Scott had some concerns about pinning the data space too. That is > is why I left the data TLB pinning behind the the config option. > > How to make better use of the remaining ITLB slots is tricky. > Somehow one would want to map at lest one to modules but I cannot see how. >
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S index bca22fa..0c2bf00 100644 --- a/arch/powerpc/kernel/head_8xx.S +++ b/arch/powerpc/kernel/head_8xx.S @@ -704,7 +704,7 @@ start_here: */ initial_mmu: tlbia /* Invalidate all TLB entries */ -#ifdef CONFIG_PIN_TLB +#if 1 /* CONFIG_PIN_TLB */ lis r8, MI_RSV4I@h ori r8, r8, 0x1c00 #else
Various kernel asm modifies SRR0/SRR1 just before executing a rfi. If such code crosses a page boundary you risk a TLB miss which will clobber SRR0/SRR1. Avoid this by always pinning kernel instruction TLB space. Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> --- arch/powerpc/kernel/head_8xx.S | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)