Date: Fri, 31 Jan 2003 13:15:38 -0500 (EST) From: Gary Thorpe <gathorpe79@yahoo.com> To: "Andrew R. Reiter" <arr@watson.org>, Julian Elischer <julian@elischer.org> Cc: David Schultz <dschultz@uclink.berkeley.edu>, Terry Lambert <tlambert2@mindspring.com>, Scott Long <scott_long@btc.adaptec.com>, arch@FreeBSD.ORG Subject: Re: PAE (was Re: bus_dmamem_alloc_size()) Message-ID: <20030131181538.80926.qmail@web41206.mail.yahoo.com> In-Reply-To: <Pine.NEB.3.96L.1030130140635.27249A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--- "Andrew R. Reiter" <arr@watson.org> wrote: > On Thu, 30 Jan 2003, Julian Elischer wrote: > [...] > :The reason for PAE is simple. > : > :Disk caches need not be in mapped memory. Physical memory will do. > :If you want to cache more than 4GB, then PAE is an effective > answer. > : > :(Assuming I have my TLAs the right way around..) > : > : > > Ya, well Im glad you brought that up, b/c aside from the anti-PAE > rants > that have been coming across (which are of ZERO USE -- THX FOR THAT), > I > do believe there are uses for it. I am glad to hear that someone is > on > it :) Thanks to them and those who organized the project for it. > > Cheers, > Andrew > > -- > Andrew R. Reiter > arr@watson.org > arr@FreeBSD.org 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? ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca 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?20030131181538.80926.qmail>