On Wed, May 29, 2002 at 09:34:54PM -0400, Dan Malek wrote:

Paul Mackerras wrote:

quoted

I suspect we are all confusing two things here: (1) having pinned TLB
entries and (2) using large-page TLB entries for the kernel.

I wasn't confusing them :-).  I know that large page sizes are beneficial.
Someday I hope to finish the code that allows large page sizes in the
Linux page tables, so we can just load them.

Well it so happens that Paul and I have tried implementing that this
morning.  More data coming in the next day or two.

quoted

We could have (2) without pinning any TLB entries but it would take
more code in the TLB miss handler to do that.

Only on the 4xx.  I have code for the 8xx that loads them using the
standard lookup.  Unfortunately, I have found something that isn't quite
stable with the large page sizes, but I don't know what it is.

I'm only talking about 4xx.

quoted

....  It is an interesting
question whether the benefit of having the 64th TLB slot available for
applications would outweigh the cost of the slightly slower TLB
misses.

Removing the entry will increase the TLB miss rate by 1/64 * 100 percent,
or a little over 1.5%, right?  Any application that is thrashing the TLB
cache by removing one entry is running on luck anyway, so we can't consider
those.  When you have applications using lots of CPU in user space (which
is usually a good thing :-), increased TLB misses will add up.

Um, assuming a program with some degree of locality, I'd expect it to
increase the miss rate by somewhat less than 1/64, but it will
certainly increase them to an extent.  So, show us the data.

quoted

.... My feeling is that it would be a close-run thing either way.

So, if you have a product that runs better one way or the other, just
select the option that suits your needs.  If the 4xx didn't require the
extra code in the miss handler to fangle the PTE, large pages without
pinning would clearly be the way to go (that's why it's an easy decision
on 8xx and I'm using it for testing).

Actually from the looks of this implementation doing large pages won't
be too bad - we can hijack an existing test so we only hit the extra
code if we hit a large page entry.  Tests coming soon, I would expect
it to beat the current CONFIG_PIN_TLB.

quoted

.... David's suggestion was purely in the context of the 405
processor, which has 64.

There is an option to enable it, so just enable it by default.  What
do you gain by removing the option, except the possibility to prevent
someone from using it when it may be to their benefit?  It certainly
isn't a proven modification, as there may be some latent bugs associated
with dual mapping pages that may be covered by the large page and
some other mapping (I think this is the problem I see on the 8xx).

We gain simplicity of code.  Feeping creaturism isn't a good thing.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/