Re: cvs commit: src/sys/alpha/alpha machdep.c

[ Available lists | Index of cvs-all | Month of Feb 2003 | Week of 16 Feb 2003 | Raw email | View thread | Wrap long lines | Reply | Tag ]
From
Peter Wemm <peter@wemm.org>
Date
16 Feb 2003 23:26:16
Subject
Re: cvs commit: src/sys/alpha/alpha machdep.c
Message-ID
20030217072612.577382A89E@canning.wemm.org


[ Hide this part ]
"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



Elapsed time: 0.151 seconds