From owner-freebsd-hackers Wed Jun 2 11:16:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 1AFAB1540E for ; Wed, 2 Jun 1999 11:16:41 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id LAA14736; Wed, 2 Jun 1999 11:16:33 -0700 (PDT) Message-Id: <199906021816.LAA14736@lestat.nas.nasa.gov> To: Arun Sharma Cc: hackers@FreeBSD.ORG Subject: Re: pv_table/pv_entry Reply-To: Jason Thorpe From: Jason Thorpe Date: Wed, 02 Jun 1999 11:16:32 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 1 Jun 1999 18:08:35 -0700 Arun Sharma 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. NetBSD's UVM is the same way. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message