From: Dan Malek <dan@netx4.com>
To: Christer Weinigel <wingel@cendio.se>
Cc: alan@packetengines.com, linuxppc-embedded@lists.linuxppc.org
Subject: Re: WARNING OFF TOPIC SLIGHTLY: 8xx MMU w/8MB pages
Date: Tue, 18 Jan 2000 13:56:57 -0500 [thread overview]
Message-ID: <3884B779.25C15918@netx4.com> (raw)
In-Reply-To: 200001181828.TAA23940@dumburk.cendio.se
Christer Weinigel wrote:
> ........ Set the 4/16k bit in
> MD_RPN to 1 and it'll work. Apparently, the two page size bits in
> MD_TWC and the bit från MD_RPN together form the real page size. The
> documentation is a bit misleading here.
That is the proper thing to do, but not exactly the reason. You
should also set MD_CTR.TWAM = 1, since the problem you are solving
is telling the MMU not to use 4K/1K subpages.
> Now I'd just like to know why I can't get 8 MB pages working with the
> Linux page tables.
How much software are you trying to modify in the generic Linux MM
functions? If none, it isn't likely to work except in one condition.
You will have to wire the pages into permanent TLB entries, and
move the kernel VM map around to ensure dynamically allocated
pages don't overlap the 8M "pages". This is the first and easiest
to do, but......
> .... The performance boost from putting the Linux
> kernel in an 8 MB page on a MPC850 is rather impressive, most lmbench
> system call benchmarks went twice as fast.
....lmbench is not necessary representative of embedded applications.
Performing the above modification to some of the embedded applications
I have developed would reduce the performance because the number of
TLB entries in the 850 or 823 is rather small.
As I have said in previous messages, you can find quick little
hacks like this that may help a specific application, but they
are not generically beneficial. The real solution is to significantly
modify the Linux VM macros and functions to allow a better formatted
page table and reduce the amount of instructions in the TLB handler.
Further, we could leverage a variety of page sizes simultaneously.
This has been on my list for a long time, but isn't a trivial
weekend project (especially with the VM changes in 2.3.xx).
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2000-01-18 18:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-01-18 18:28 WARNING OFF TOPIC SLIGHTLY: 8xx MMU w/8MB pages Christer Weinigel
2000-01-18 18:56 ` Dan Malek [this message]
2000-01-18 19:11 ` Alan Mimms
2000-01-19 16:04 ` Dan Malek
2000-01-18 19:55 ` Christer Weinigel
-- strict thread matches above, loose matches on Subject: below --
2000-01-17 22:59 Alan Mimms
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=3884B779.25C15918@netx4.com \
--to=dan@netx4.com \
--cc=alan@packetengines.com \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=wingel@cendio.se \
/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.