Date: Wed, 29 Mar 2000 23:53:58 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Wemm <peter@netplex.com.au> Cc: "Daniel O'Connor" <doconnor@gsoft.com.au>, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/sys/alpha/include vmparam.h src/sys/conf opt Message-ID: <200003300753.XAA68882@apollo.backplane.com> References: <20000330073148.4E7BA1CD7@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:"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
<dillon@backplane.com>
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?200003300753.XAA68882>