| Message ID | 1308059700-10839-7-git-send-email-Joakim.Tjernlund@transmode.se (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
Hi Joakim. On Jun 14, 2011, at 6:54 AM, Joakim Tjernlund wrote: > Various kernel asm modifies SRR0/SRR1 just before executing > a rfi. ..... I'm going to argue we can easily visually inspect for this since the code is static with just a couple of RFIs in these exception handlers. Some 8xx processors have few TLB entries, and always taking one for the kernel, especially if it isn't needed, could have a detrimental effect on the application performance. Even the "big" 8xx processors don't have that many entries. Some benchmarks run on an MPC850 would likely show this. Anyone making modifications to this level of software should know of this problem, or make it known in a comment. If you are making changes, just compile the code and manually check it with the couple of configuration options that affect the placement of the instructions. The better solution would be supporting large page sizes, at least for the kernel. Thanks. -- Dan
Dan Malek <ppc6dev@digitaldans.com> wrote on 2011/06/14 18:06:45: > > > Hi Joakim. > > On Jun 14, 2011, at 6:54 AM, Joakim Tjernlund wrote: > > > Various kernel asm modifies SRR0/SRR1 just before executing > > a rfi. ..... > > I'm going to argue we can easily visually inspect for this > since the code is static with just a couple of RFIs in these > exception handlers. Yes, but then you also miss out on 8xx: Optimize ITLBMiss handler. > > Some 8xx processors have few TLB entries, and always taking > one for the kernel, especially if it isn't needed, could have a > detrimental effect on the application performance. Even the > "big" 8xx processors don't have that many entries. Some > benchmarks run on an MPC850 would likely show this. I don't have a mpc850, do you? > > Anyone making modifications to this level of software should > know of this problem, or make it known in a comment. If you > are making changes, just compile the code and manually > check it with the couple of configuration options that affect > the placement of the instructions. Very fragile but then again, not much are expected to change in this area for 8xx. > > The better solution would be supporting large page sizes, > at least for the kernel. Probably but that is another matter. You could continue with that if you like but I am stopping here ATM.
Hi Joakim. On Jun 14, 2011, at 11:00 AM, Joakim Tjernlund wrote: > I don't have a mpc850, do you? I have to say I do :-) > Probably but that is another matter. You could continue with that > if you like but I am stopping here ATM. Oh, come on... I've been thinking about this for years, wouldn't you like to work on it? It will be fun :-) Thanks. -- Dan
Dan Malek <ppc6dev@digitaldans.com> wrote on 2011/06/14 20:11:18: > > > Hi Joakim. > > On Jun 14, 2011, at 11:00 AM, Joakim Tjernlund wrote: > > > I don't have a mpc850, do you? > > I have to say I do :-) Good, you get to beat the crap out of it then :) > > > Probably but that is another matter. You could continue with that > > if you like but I am stopping here ATM. > > Oh, come on... I've been thinking about this for years, wouldn't > you like to work on it? It will be fun :-) Me too, but I didn't get very far though. Just had it in my mind but never got to actually looking at the code. Do you have some pointers? Jocke
Joakim Tjernlund/Transmode wrote on 2011/06/14 20:00:09: > From: Joakim Tjernlund/Transmode > > Dan Malek <ppc6dev@digitaldans.com> wrote on 2011/06/14 18:06:45: > > > > > > Hi Joakim. > > > > On Jun 14, 2011, at 6:54 AM, Joakim Tjernlund wrote: > > > > > Various kernel asm modifies SRR0/SRR1 just before executing > > > a rfi. ..... > > > > I'm going to argue we can easily visually inspect for this > > since the code is static with just a couple of RFIs in these > > exception handlers. > > Yes, but then you also miss out on 8xx: Optimize ITLBMiss handler. > > > > > Some 8xx processors have few TLB entries, and always taking > > one for the kernel, especially if it isn't needed, could have a > > detrimental effect on the application performance. Even the > > "big" 8xx processors don't have that many entries. Some > > benchmarks run on an MPC850 would likely show this. > > I don't have a mpc850, do you? > > > > > Anyone making modifications to this level of software should > > know of this problem, or make it known in a comment. If you > > are making changes, just compile the code and manually > > check it with the couple of configuration options that affect > > the placement of the instructions. > > Very fragile but then again, not much are expected to change > in this area for 8xx. So I checked and SRR0/SRR1 are fine w.r.t to head_8xx.S, it does not even come close. There are SRR0/SRR1 mods in entry.S too which works fine ATM. We don't have the same control of that file though. Could you check what impact pinning ITLB on 850 has? Jocke
diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S index c9770b6..48e9dde 100644 --- a/arch/ppc/kernel/head_8xx.S +++ b/arch/ppc/kernel/head_8xx.S @@ -785,12 +785,13 @@ start_here: */ initial_mmu: tlbia /* Invalidate all TLB entries */ -#ifdef CONFIG_PIN_TLB + +/* Always pin the first 8 MB ITLB to prevent ITLB + misses while mucking around with SRR0/SRR1 in asm +*/ lis r8, MI_RSV4I@h ori r8, r8, 0x1c00 -#else - li r8, 0 -#endif + mtspr MI_CTR, r8 /* Set instruction MMU control */ #ifdef CONFIG_PIN_TLB
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/ppc/kernel/head_8xx.S | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-)