linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>
To: Valdis.Kletnieks@vt.edu
Cc: Henti Smith <bain@tcsn.co.za>, linux-mm@kvack.org
Subject: Re: maximum possible memory limit ..
Date: Sat, 26 Apr 2003 09:11:59 +0200	[thread overview]
Message-ID: <20030426091158.O626@nightmaster.csn.tu-chemnitz.de> (raw)
In-Reply-To: <200304241835.h3OIZxvj006418@turing-police.cc.vt.edu>; from Valdis.Kletnieks@vt.edu on Thu, Apr 24, 2003 at 02:35:59PM -0400

Hi,

On Thu, Apr 24, 2003 at 02:35:59PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Thu, 24 Apr 2003 20:05:24 +0200, Henti Smith <bain@tcsn.co.za>  said:
> > I had a discussion with somebody watching the whole M$ server launch and
> > mentioned then new systems supports up to a terabyte of ram. 

> Well.. sure.. it's easy enough to write something that supports plugging in
> a terabyte.  The *tricky* part is supporting it well - you have page table
> issues, you have swapping/thrashing issues (if you *do* have to page something
> out, you're in trouble.. ;), you have process scheduling issues (how many
> Apache processes does it take to use up a terabyte?  What's your load average
> at that point?), you have multi-processor scaling issues (you're gonna want
> to have 64+ processors, etc..)

This is all a kind of DSW[1]. Consider the ordinal limits of the
data structures used to represent memory and cpus.

Since Linux uses bitmaps to represent CPUs, we can support as
much CPUs, as much of such bitmaps (there are many of them) into
memory.

numphyspages is unsigned long. That means on 64-Bit platforms you
can support up to 2^(64+PAGE_SHIFT)-1 bytes of memory.

So I think, we've won this time, but the mm-people might know even
more limiting factors to show the real theoretical limits.

> Consider - the number of machines with over a terabyte of RAM is limited:
> 
> http://www.llnl.gov/asci/platforms/platforms.html
> 
> That's the sort of box that has a terabyte.  Do you *really* think that
> M$ 2003 has all the stuff needed to scale to THAT size?

The nice thing about DSWs is, that sanity doesn't matter ;-)
And yes, this is important, as people continue to buy useless and
oversized things to compensate for something.

PS: CC'ed to linux-mm instead of linux-kernel.

Regards

Ingo Oeser
[1] Dick Size War
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

           reply	other threads:[~2003-04-26  7:11 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <200304241835.h3OIZxvj006418@turing-police.cc.vt.edu>]

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=20030426091158.O626@nightmaster.csn.tu-chemnitz.de \
    --to=ingo.oeser@informatik.tu-chemnitz.de \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=bain@tcsn.co.za \
    --cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox