[RFC/PATCH,2/2] powerpc: 44x doesn't need G set everywhere

After discussing with chip designers, it appears that it's not
necessary to set G everywhere on 440 cores. The various core
errata related to prefetch should be sorted out by firmware by
disabling icache prefetching in CCR0. We add the workaround to
the kernel however just in case oooold firmwares don't do it.

This is valid for -all- 4xx core variants. Later ones hard wire
the absence of prefetch but it doesn't harm to clear the bits
in CCR0 (they should already be cleared anyway).

We still leave G=1 on the linear mapping for now, we need to
stop over-mapping RAM to be able to remove it.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---

 arch/powerpc/kernel/head_44x.S |   12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

On Wed, 10 Dec 2008 16:50:50 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> After discussing with chip designers, it appears that it's not
> necessary to set G everywhere on 440 cores. The various core
> errata related to prefetch should be sorted out by firmware by
> disabling icache prefetching in CCR0. We add the workaround to
> the kernel however just in case oooold firmwares don't do it.
> 
> This is valid for -all- 4xx core variants. Later ones hard wire
> the absence of prefetch but it doesn't harm to clear the bits
> in CCR0 (they should already be cleared anyway).
> 
> We still leave G=1 on the linear mapping for now, we need to
> stop over-mapping RAM to be able to remove it.

Hm.  Over-mapping it has the nice advantage that we use as few pinned
TLB entries as possible.  For 440x6 cores with more than 256 MiB of
DRAM, you could theoretically use a single 1GiB TLB entry to map all
kernel DRAM.

Do you think the trade-offs of allowing speculative accesses are worth
the increased TLB pressure?  Large base pages will help with that in
some workloads, but others are still going to be TLB constrained.

I know, I'm probably paranoid.  But changing things like this around
without some kind of benchmark data or testcase to make sure we aren't
making it worse gives me the heebee-geebees.

josh

> > We still leave G=1 on the linear mapping for now, we need to
> > stop over-mapping RAM to be able to remove it.
> 
> Hm.  Over-mapping it has the nice advantage that we use as few pinned
> TLB entries as possible.  For 440x6 cores with more than 256 MiB of
> DRAM, you could theoretically use a single 1GiB TLB entry to map all
> kernel DRAM.

Ok well, there are several issues here.. see below

> Do you think the trade-offs of allowing speculative accesses are worth
> the increased TLB pressure?  Large base pages will help with that in
> some workloads, but others are still going to be TLB constrained.
> 
> I know, I'm probably paranoid.  But changing things like this around
> without some kind of benchmark data or testcase to make sure we aren't
> making it worse gives me the heebee-geebees.

Yup, which is why I'm not changing it yet :-) My initial thinking was
along the lines of: We can use up to 4 bolted TLB entries, that will
cover most classic memory configurations such as 256, 512 etc.... and
leave what doesn't fit to highmem.

However that fails miserably with 128M which is quite common.

Then I thought we could overmap and use G for things that don't quite
fit and remove G when we know we can do an exact mapping...

Then I though .. heh, first we know there is no speculative or
prefetched data access on 440. We also know that speculative /
prefetched instruction access is busted and must be disabled.

Thus can't we just both overmap and not have G ?

Needs testing of course :-) I'm waiting for an answer from the chip guys
here.

G=1 has some other impacts, such as preventing write combining I think,
re-ordering, and a few other things.

Cheers,
Ben.

On Thu, 11 Dec 2008 07:03:57 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> 
> > > We still leave G=1 on the linear mapping for now, we need to
> > > stop over-mapping RAM to be able to remove it.
> > 
> > Hm.  Over-mapping it has the nice advantage that we use as few pinned
> > TLB entries as possible.  For 440x6 cores with more than 256 MiB of
> > DRAM, you could theoretically use a single 1GiB TLB entry to map all
> > kernel DRAM.
> 
> Ok well, there are several issues here.. see below
> 
> > Do you think the trade-offs of allowing speculative accesses are worth
> > the increased TLB pressure?  Large base pages will help with that in
> > some workloads, but others are still going to be TLB constrained.
> > 
> > I know, I'm probably paranoid.  But changing things like this around
> > without some kind of benchmark data or testcase to make sure we aren't
> > making it worse gives me the heebee-geebees.
> 
> Yup, which is why I'm not changing it yet :-) My initial thinking was
> along the lines of: We can use up to 4 bolted TLB entries, that will
> cover most classic memory configurations such as 256, 512 etc.... and
> leave what doesn't fit to highmem.
> 
> However that fails miserably with 128M which is quite common.
> 
> Then I thought we could overmap and use G for things that don't quite
> fit and remove G when we know we can do an exact mapping...
> 
> Then I though .. heh, first we know there is no speculative or
> prefetched data access on 440. We also know that speculative /
> prefetched instruction access is busted and must be disabled.
> 
> Thus can't we just both overmap and not have G ?
> 
> Needs testing of course :-) I'm waiting for an answer from the chip guys
> here.

Heh.  I like it.

> G=1 has some other impacts, such as preventing write combining I think,
> re-ordering, and a few other things.

Yeah.

Overall, I'm OK with changing things as long as we can sort of prove we
aren't making it worse.

josh