Date: Wed, 2 Jun 1999 15:16:31 -0700 From: Arun Sharma <adsharma@home.com> To: Jason Thorpe <thorpej@nas.nasa.gov> Cc: hackers@FreeBSD.ORG Subject: Re: pv_table/pv_entry Message-ID: <19990602151631.A30920@home.com> In-Reply-To: <199906021816.LAA14736@lestat.nas.nasa.gov>; from Jason Thorpe on Wed, Jun 02, 1999 at 11:16:32AM -0700 References: <199906021816.LAA14736@lestat.nas.nasa.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 02, 1999 at 11:16:32AM -0700, Jason Thorpe wrote: > On Tue, 1 Jun 1999 18:08:35 -0700 > Arun Sharma <adsharma@home.com> wrote: > > > Going through the 4.4 BSD book, I learnt that the purpose of the pv_table > > is to be able to locate all the mappings to a given physical page. > > > > However, comparing this to the Linux approach, which chains vm_area_struct > > (analogous to vm_map_entry in FreeBSD) together to locate the shared > > mappings, it appears to me that the Linux approach is more space efficient. > > > > So why not eliminate pv_table and chain vm_map_entries together to represent > > the sharing information ? > > ....because in the Mach VM system (which is what FreeBSD is derived from), > map entries may represent several virtual (and thus physical) pages. > That's right. But by chaining vm_map_entries, you don't lose any sharing information. You can _infer_ the same information by walking the vm_map_entries. By keeping the pv_table, you're making it explicit, which makes certain operations very fast - at the cost of some space. The overhead seems to be a constant of 0.4% + sizeof(pv_entry) * degree of sharing. Sounds like a good trade off to me. -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990602151631.A30920>