Date: Thu, 6 Jun 2002 15:24:58 +0200 From: Miguel Mendez <flynn@energyhq.homeip.net> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-hackers@freebsd.org Subject: Re: allocating memory Message-ID: <20020606152458.A81446@energyhq.homeip.net> In-Reply-To: <3CFF4FE8.86C44C31@mindspring.com>; from tlambert2@mindspring.com on Thu, Jun 06, 2002 at 05:04:56AM -0700 References: <3CFEEB99.AEDC5DB9@math.missouri.edu> <3CFF2780.FAD81226@mindspring.com> <20020606122702.A81113@energyhq.homeip.net> <3CFF4FE8.86C44C31@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--SLDf9lqlvOQaIe6s
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Jun 06, 2002 at 05:04:56AM -0700, Terry Lambert wrote:
Hi,
> The SPARC 64 that's probably not going to see a lot of use until the
> number of 64 bit SPARC machines available second-hand comes anywhere
> close to 10% of the 32 bit SPARC machines that can be had out there;
> in terms of price/performance, they are still way too expensive. I
How come? A Sun Blade 100 is about $1,000. That's not what I call
expensive. It's not an E4500, but not a bad box once you load it with a
bit more RAM and a SCSI controller. You can get Ultra 10 boxen pretty
cheap these days too.
> guess if I didn't limit your remarks to FreeBSD, and included Solaris,
> AIX, or NetBSD as options, the field would be larger.
Yes, I'd include those OS, as FreeBSD is not, and won't be, production
ready for a while for those platforms.
> You didn't mention the Alpha, but Alpha is end of life these days,
> now that HP owns what Intel didn't already own. The FreeBSD Alpha
I didn't even consider the Alpha as a viable option. Compaq^WHP took
care of killing it, and, it for any reason it survives, Fiorina will
take care of it. It's sad, the Alpha is a very nice arch to work with.
But in these days, I don't consider it anything more useful than my old
Amiga 1200, nice box, but pretty much useless now.
> port (which *is* complete) unfortunately can't handle more than 2G
> of RAM (apparently, this has to do with the I/O architecture issues
> that have yet to be resolved completely, by way of code changes
> that *should* happen, but haven't, because the i386 doesn't need
> them to happen).
It seems to me most developers have lost interest in it and moved
already towards more exciting targets, like the sparc port.
> It's not there; there would have been a big announcement, I think,
> like "Hyperthreading" (really, SMT). Peter Wemm was reported by
> Alfred Perlstein to have been working on it. If Peter is on it, it
Well, now *that* would be interesting to see, as a hacker exercise.
> [ ...Skip to the end if you love PAE, and don't want to
> read anyone "insulting" it... ]
Not really, I don't like any more than the other gazillion kludges the
PC arch is built upon :)
> The problem with PAE is that, while it extends the amount of
> physical RAM you can access, it doesn't extend the amount of
> physical RAM you can access *simultaneously*. It also doesn't
> increase your kernel or user virtual address space: the total
> of the two still can't exceed 4G, even when using PAE.
Agreed, more on that below.
> It's basically the 32 bit version of the 16 bit bank selection
> in the Commodore64, or if you want to dig deeper, the bank
Well, you don't need to go that far in history, just boot your computer
and enjoy a 500Mhz cpu with 64KB segments :)
> What do you get out of PAE? Faster, very low granularity swap,
> that eventually becomes much more expensive to LRU out to real
> swap, once it's all filled up (guaranteed: your least recently
> used data is not in the bank that's currently selected in!).
Okay, this is where I wanted to get. First you need to do some hacking
because pointers for Intel processors are 32 bits in size, so a possible
solution could be:
Assume a (software based) 64bit address space, by means of using long
long for pointers. Of course you can only access a 4GB chunk at a time,
but programs need not to know about that. Do they want to malloc or mmap
8GB? You let them. If the program is doing random access all the time,
it will spend a lot of time in kernel, as not only pages, but segments
have to be taken in account when accessing a memory location. It would
work pretty well for programs doing consecutive accesses to their
dataset (or within the 4GB boundary). Doing some MMU magic you can have
a transparent system to allow programs use more than 4GB.
Maybe if/when that hardware becomes affordable I'll try myself such a hack =
:)
> In other words, if you need X G of RAM, then 4 times that much
> is not going to save you, and you need to reconsider your code.
Databases for one love to have huge amounts of memory. It's not uncommon
to have e.g. informix processes using 16GB of ram on Sun big iron.
> You can't DMA into the thing. If you have a 64 bit PCI, and your
IMHO not an issue.
> What this boils down to is that the physical RAM ends up getting
> used up for housekeeping of the physical RAM. You can push this
> up closer to 3G; but to do that, you have to make modifications
> to pmap.c and machdep.c.
Such an enhancement needs a lot of modifications to the VM subsystem.
> housekeeping for. So the only real approach is to got to a
> MIPS-like software lookaside (hierarchical) so that you can
> take each bank, and take the 1/4 out of the bank itself. This
> works, but it's incredibly expensive, overall.
Hmm, yes. So what does Windows 2000 Datacenter do wrt that problem?
Waste memory like there's no tomorrow?
> Basically ...the memory is only good for programs themselves,
> not for DMA, mmap'ed files, more mbufs... anything really useful.
Of course, it's the applications demanding memory we are talking about.
For the OS itself, it's just a half assed solution, no practical at all.
> Now add in that most new, fast memory is actually limited to
> 2G in a system because of the memory modules being used (e.g.
> the new 450MHz memory busses can't handle more than 2G).
Add more memory buses :)
> FreeBSD uses the standard recursive mapping, and it uses soft
> switching, which means that it has a small TSS profile (Intel
Yes, TSS is one of the many instructions that nobody uses. And looking
at the poor register set in the x86 ISA, it's blatantly obvious they
never asked a software engineer :-)
> priority processes, you prefer the ones that are in the same
> bank as the current process.
I'd keep all .text pages in the low 4GB of the machine. The probability
that a program's code is bigger than that is, imho, null.
> The bottom line is that, in order to have a *usable* amount of
> physical RAM over 4G, you pretty much have to go to a 64 bit
> platform, and if you are a user, now that Alpha is dead and no
> one looks to be making quick progress on the Alpha 2G barrier,
> that pretty much means "Itanium".
Except Itanium is nowhere production ready, so you probably need
something else, e.g. sparc or ppc. Mips is also a nice arch to work
with, btw, unfortunately SGI hardware is extremely expensive.
Cheers,
--=20
Miguel Mendez - flynn@energyhq.homeip.net
GPG Public Key :: http://energyhq.homeip.net/files/pubkey.txt
EnergyHQ :: http://www.energyhq.tk
FreeBSD - The power to serve!
--SLDf9lqlvOQaIe6s
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (FreeBSD)
iD8DBQE8/2KqnLctrNyFFPERAt24AKCuoD2UQ8LuTP0VkXIg3wNkFekwvgCgh4fT
0vu1L0SSBBUVMP77m+J8XBI=
=WYs/
-----END PGP SIGNATURE-----
--SLDf9lqlvOQaIe6s--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020606152458.A81446>