On Thu, 11 Dec 2008 07:03:57 +1100 Benjamin Herrenschmidt <[EMAIL PROTECTED]> 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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
