From: Frank Rowand <frank_rowand@mvista.com>
To: Dan Malek <dan@mvista.com>
Cc: Ralph Blach <rcblach@raleigh.ibm.com>,
frowand@mvista.com,
linuxppc-dev <linuxppc-dev@lists.linuxppc.org>
Subject: Re: kernel mapping
Date: Tue, 16 Jan 2001 11:56:02 -0800 [thread overview]
Message-ID: <3A64A751.8AA527CF@mvista.com> (raw)
In-Reply-To: 3A647BC7.15F669F3@mvista.com
Dan Malek wrote:
>
> Ralph Blach wrote:
> >
> > Why do we need simulated bat registers.
>
> To improve performance. Right now, on the 4xx there is the
> concept of "pinned" TLB entries to reduce/eliminate TLB misses
> on large mapped areas (like kernel text/data or I/O). The 8xx
> does this in some custom applications as well. These are just
> hacks that are headed down a disastrous maintenance path that
> need to be stopped now for a more generic solution.
At the moment, the 405 processors _require_ kernel memory to be
pinned because the tlb miss handlers use virtual addresses. When
I started the 405 port I planned to move the TLB handlers into
assembly running in real mode. Then when I started seeing info
about the 440 I backed away from that plan because the 440 always
runs with the MMU enabled. I'm still thinking about the 440...
I pinned some IO ranges as a convenience when I was first porting
to the 405gp but plan to remove those pins. Though I'm somewhat
tempted to leave a pin in place for the on-chip ethernet device
if performance measurements show a significant gain.
> I have been experimenting with many different methods of using
> the "large" page table sizes through the generic memory management
> methods that already exist in the kernel. I believe I can wrap
> the concept of the pinned TLB entries into the same logic as BAT
> register management on the bigger processors. Hence, I call them
> simulated BAT registers....the semantics aren't quite the same.
I think that's a good idea. If you do so, please provide a way to
force an entry to be locked in the tlb.
> The BAT registers are a really good thing, and although the large
> page size TLB entries are more flexible, they require more software
> overhead. I would like to make some generic Linux MM modifications
> to help us support variable page sizes, but I suspect that will
> never happen.
>
> -- Dan
I've toyed with the variable pages sizes idea too, and it just hasn't
moved up high enough on my priority list. I'm not sure I'm quite as
pessimistic as you about whether it will ever happen because several
other architecture support variable page sizes (including pa-risc
and (I think) IA-64).
-Frank
--
Frank Rowand <frank_rowand@mvista.com>
MontaVista Software, Inc
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2001-01-16 19:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-15 23:13 kernel mapping Dan Malek
2001-01-16 3:07 ` Frank Rowand
2001-01-16 3:55 ` Dan Malek
2001-01-16 11:37 ` Ralph Blach
2001-01-16 16:50 ` Dan Malek
2001-01-16 17:10 ` Ralph Blach
2001-01-16 17:47 ` David Edelsohn
2001-01-16 21:57 ` Dan Malek
2001-01-17 10:51 ` Gabriel Paubert
2001-01-17 17:45 ` David Edelsohn
2001-01-16 19:56 ` Frank Rowand [this message]
2001-01-16 22:13 ` Dan Malek
2001-01-17 0:04 ` Frank Rowand
2001-01-17 7:02 ` Dan Malek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3A64A751.8AA527CF@mvista.com \
--to=frank_rowand@mvista.com \
--cc=dan@mvista.com \
--cc=frowand@mvista.com \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=rcblach@raleigh.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.