From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: MIPS addressing limits, Was: Re: CVS Update@-mips.org: linux
Date: Wed, 15 Oct 2003 16:59:48 +0200 [thread overview]
Message-ID: <20031015145948.GB23514@linux-mips.org> (raw)
In-Reply-To: <Pine.GSO.3.96.1031015161040.9299D-100000@delta.ds2.pg.gda.pl>
On Wed, Oct 15, 2003 at 04:23:06PM +0200, Maciej W. Rozycki wrote:
> > Still want more? A 3 level tree would then cover 128TB of virtual
> > address space already exceedin the hardware limits of all processors but
> > the R8000.
>
> Well, the MIPS64 ISA spec allows up to 8EB of user memory to be supported
> by an implementation, IIRC; probably nothing supports that much yet,
> though. ;-) BTW, is an R8000 spec available online anywhere?
There used to be a few papers published by SGI online and various other
bits of information I found through google.
(I happen to have a paper copy of the R8000 manual but since the responsible
people still haven't informed me if I can legally use it, this book is
closed and will stay closed until this happens - if ever ... Pitty, I
still receive mails from various R8000 users ...)
> > 64k pagesize stretches the limits even further. Here a two level
> > pagetable tree would cover 4TB, 3-level could cover 32PB exceeding
> > the capacity of every MIPS processor ever made - and probably sufficient
> > for the coming decade :-)
>
> Further increasing of the page size should result in better performance
> due to fewer TLB misses and reduce the memory footprint of page tables,
> but the drawback is more memory is wasted for maps. Whether the end
> result is a gain or a loss depends on the actual application of a system,
> so I guess we should either leave the size configurable (with a sane
> default for those who might have troubles judging what would suit them
> best) or only decide on a given size after lots of benchmarking.
Unless somebody yells I almost feel like ditching 3-level pagetable
support; 2-levels with a decent pagesize should suffice for a few years
to come ...
Ralf
next prev parent reply other threads:[~2003-10-15 15:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20031013142637Z8225419-1272+7775@linux-mips.org>
[not found] ` <Pine.GSO.3.96.1031014114452.17028B-100000@delta.ds2.pg.gda.pl>
2003-10-14 13:28 ` CVS Update@-mips.org: linux Ralf Baechle
2003-10-15 14:23 ` Maciej W. Rozycki
2003-10-15 14:59 ` Ralf Baechle [this message]
2003-10-15 17:19 ` MIPS addressing limits, Was: " Jun Sun
2003-10-15 17:42 ` Ralf Baechle
2003-10-19 20:09 ` Nick
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=20031015145948.GB23514@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=linux-mips@linux-mips.org \
--cc=macro@ds2.pg.gda.pl \
/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.