Date: Sun, 16 Feb 2003 23:26:12 -0800 From: Peter Wemm <peter@wemm.org> To: "Alan L. Cox" <alc@imimic.com> Cc: Marcel Moolenaar <marcel@xcllnt.net>, Andrew Gallatin <gallatin@cs.duke.edu>, src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/alpha machdep.c Message-ID: <20030217072612.577382A89E@canning.wemm.org> In-Reply-To: <3E500717.65436EAF@imimic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Alan L. Cox" wrote:
> Marcel Moolenaar wrote:
> >
> > On Sun, Feb 16, 2003 at 02:34:15PM -0500, Andrew Gallatin wrote:
> > > Andrew Gallatin [gallatin@FreeBSD.org] wrote:
> > > > gallatin 2003/02/16 11:25:04 PST
> > > >
> > > > Modified files:
> > > > sys/alpha/alpha machdep.c
> > > > Log:
> > > > zero the end of the memory cluster we're disposing of. Otherwise teh
> > > > vm page startup code finds a 20GB cluster on this wacky alphaserver I
'm
> > > > working on..
> > >
> > > Anybody know why phys avail is so cryptic? Does it come directly from
> > > AT&T and predate C support structures?
> >
> > It's probably one of those quick-n-dirty hacks to get something
> > going. It's polluting new architectures as well, because it's in
> > MI code. I don't think there's a reason why it must absolutely
> > be the way it is...
> >
>
> It came with i386/i386/machdep.c revision 1.25.
And it is (or was) extremely performance critical. That's why it was so
obscure and why there was such a short limit of 5 physical memory chunks on
i386. That doesn't necessarily mean that its worth it though.
I believe we have bigger problems in the MI code.. we allocate the
vm_page_t array to cover a linear range from the lowest entry in
phys_avail to the highest entry address. This means that if we have
machines that have 2G of ram at address 0 and another 2G at the 16G mark,
then that means that the MI vm code allocates enough vm_page_t's in a
linear array to to cover 18G of physical space. Needless to say, this
is a waste especially given that nearly all systems with PCI split it up
like this. ie: no more than 2G in the first 4G of "32 bit pci reachable
space" and the rest above 4G.
This has annoyed me for years. This has persisted because PHYS_TO_VM_PAGE()
needs it to be fast because folks have cheated and abused it in MI code
that really should be fixed to not need it.
I note that somebody has been tinkering with this. I saw this in
somebody's tree:
#ifdef SPARSE_PHYSICAL_MEMORY
#define PHYS_TO_VM_PAGE(pa) vm_page_from_phys(pa)
#else
#define PHYS_TO_VM_PAGE(pa) (&vm_page_array[atop(pa) - first_page ])
#endif
However, it then walks the phys_avail[] array. So all the abusers of
PHYS_TO_VM_PAGE() in MI code get to pay for it. And there are lots :-(
Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030217072612.577382A89E>