From owner-cvs-all Wed Mar 29 23:54:22 2000 Delivered-To: cvs-all@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id F213237B510; Wed, 29 Mar 2000 23:54:12 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA68882; Wed, 29 Mar 2000 23:53:58 -0800 (PST) (envelope-from dillon) Date: Wed, 29 Mar 2000 23:53:58 -0800 (PST) From: Matthew Dillon Message-Id: <200003300753.XAA68882@apollo.backplane.com> To: Peter Wemm Cc: "Daniel O'Connor" , cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/sys/alpha/include vmparam.h src/sys/conf opt References: <20000330073148.4E7BA1CD7@overcee.netplex.com.au> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :"Daniel O'Connor" wrote: :> :> On 30-Mar-00 Peter Wemm wrote: :> > that comment is bogus.. The only practical limit is how much physical :> > ram you want to lock up as this stuff isn't paged out or swap backed. :> :> Is it [easily] possible to make its pageable? : :I don't know. Probably, if one wanted to cut/paste code from the likes :of the swap-backed code in the vn device. I couldn't find the beginning of this thread, but if you are talking about making the PV entries pageable, it isn't possible. :However, the other reason I'm not sure about making it pageable is that in :a certain scenario making it pageable rules out a possible optimization. :For example, an Oracle server, with a 1G shm segment (262144 pages) mapped :into 300 processes consumes about 78643200 pv entries. At 28 bytes each :that is 2202009600 bytes of ram (2100MB), *just for the pv entries*. :Naturally this sucks as the pv entries are thrashed to hell. : :One of the main reasons for pv entries existing is to locate all virtual :addresses in all processes that a given page occupies in order to rapidly :unwire it during pageout. If the pages are never paged out and are :permanently wired, then perhaps we could cheat somewhere and *not use* pv :entries for these shm pages. This would make an astronomical difference to :our Oracle TPS performance. Of course, it may not be possible to do this :for other reasons, but making it pageable would guarantee it for now :without rearchitecting the whole pv entry system (which is outside the scope :of a quick hack to make oracle work better). : :Cheers, :-Peter I think the best solution is to detect the common-shared-mapping-at-same-va case and then physically share the associated page table pages (i.e. the mmu segments) between otherwise unassociated processes. This would reduce the number of discrete page tables by a factor of around 200 in the oracle case and thus decrease the number of PV entries by the same. I haven't had time to look into this deeply yet, there are some obvious issues that would have to be worked out to make it work. Changing the core characteristics of the PV structure is pretty much out of the question short of rewriting pmap.c entirely. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message