All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jun Sun <jsun@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: MIPS addressing limits, Was: Re: CVS Update@-mips.org: linux
Date: Wed, 15 Oct 2003 10:19:02 -0700	[thread overview]
Message-ID: <20031015101902.C8761@mvista.com> (raw)
In-Reply-To: <20031015145948.GB23514@linux-mips.org>; from ralf@linux-mips.org on Wed, Oct 15, 2003 at 04:59:48PM +0200

On Wed, Oct 15, 2003 at 04:59:48PM +0200, Ralf Baechle wrote:
> 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 ...
> 

Isn't ia64 still using 3-level page tables?  Any performance data we
can infer from theirs?

I feel a little uneasy about ditching 3-level pagetable altogether.
Leaving all the parameters configurable, including the possiblity of
nullifying the second level and changing page size, seems to be a more 
comforting thought.

Jun

  reply	other threads:[~2003-10-15 17:19 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       ` MIPS addressing limits, Was: " Ralf Baechle
2003-10-15 17:19         ` Jun Sun [this message]
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=20031015101902.C8761@mvista.com \
    --to=jsun@mvista.com \
    --cc=linux-mips@linux-mips.org \
    --cc=macro@ds2.pg.gda.pl \
    --cc=ralf@linux-mips.org \
    /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.