From owner-cvs-all Sun Feb 16 23:26:16 2003 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11AFA37B401; Sun, 16 Feb 2003 23:26:13 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72F4E43FB1; Sun, 16 Feb 2003 23:26:12 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 577382A89E; Sun, 16 Feb 2003 23:26:12 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Alan L. Cox" Cc: Marcel Moolenaar , Andrew Gallatin , src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/alpha machdep.c In-Reply-To: <3E500717.65436EAF@imimic.com> Date: Sun, 16 Feb 2003 23:26:12 -0800 From: Peter Wemm Message-Id: <20030217072612.577382A89E@canning.wemm.org> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "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