Skip site navigation (1)Skip section navigation (2)
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>