Thread (5 messages) flat view 5 messages, 2 authors, 2002-06-06

Re: LMbench results for large page patch

From: David Gibson <hidden>
Date: 2002-06-06 07:57:32

On Thu, Jun 06, 2002 at 03:30:16AM -0400, Dan Malek wrote:
David Gibson wrote:
quoted
....There are a couple of things largepte still does better
on, main memory latency (expected) and exec proc (unexpected).  The
difference is small though.
The exec proc does lots of VM updates and TLB management.  The pinned
TLBs on the 4xx require additional management overhead to ensure they
aren't flushed when it is viewed as quicker to just flush the TLB.
The exec proc tests don't accomplish any useful work once the system
resources are allocated, so you are continually turning over the TLB and
any additional managemant will appear in this overhead.
Ah yes, that makes sense.  In particular _tlbia() will be much slower
with pinned TLBs than without.
quoted
largepte still does as well or better than nopintlb in
essentially every case.
Which is expected....now if we could just extend this to applications, we
would really have something :-)
So are you ok with the notion of merging the large page stuff and
abolishing CONFIG_PIN_TLB, once I've made iopa() and mapin_ram() less
ugly than they are in that first cut?

--
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/
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help