Date: Fri, 31 Jan 2003 16:47:36 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Peter Wemm <peter@wemm.org> Cc: Gary Thorpe <gathorpe79@yahoo.com>, "Andrew R. Reiter" <arr@watson.org>, Julian Elischer <julian@elischer.org>, David Schultz <dschultz@uclink.berkeley.edu>, Scott Long <scott_long@btc.adaptec.com>, arch@FreeBSD.ORG Subject: Re: PAE (was Re: bus_dmamem_alloc_size()) Message-ID: <3E3B1928.384F8C42@mindspring.com> References: <20030131184326.D70A42A89E@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Wemm wrote: > Gary Thorpe wrote: > > Would this be part of a unified buffer-cache scheme though? If I have > > been following correctly, this memory cannot be directly mapped into > > processes address space (i.e. a process in one "segment" cannot access > > directly memory in another "segment"), so how would it be useful as a > > cache? Wouldn't this need lots of data copying as in bounce buffers? > > It the nasty PSE36 hack that cant be used for this. PAE works fine as > cache since it is all available to all processes. What Peter said: the thing you don't get is the ability to have more than 4G of KVA + UVA space, unless you split the VM and buffer cache. Also what Peter said about the performance penalty that comes from PAE, and what I said about the reliability penalty from #ifdef'ing and seperately maintaining the code side-by-side. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E3B1928.384F8C42>