From owner-freebsd-hackers  Wed Jun  2 15:16:36 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from mail.rdc1.sfba.home.com (ha1.rdc1.sfba.home.com [24.0.0.66])
	by hub.freebsd.org (Postfix) with ESMTP id 23AB414CAA
	for <hackers@FreeBSD.ORG>; Wed,  2 Jun 1999 15:16:32 -0700 (PDT)
	(envelope-from adsharma@c62443-a.frmt1.sfba.home.com)
Received: from c62443-a.frmt1.sfba.home.com ([24.0.69.165])
          by mail.rdc1.sfba.home.com (InterMail v4.01.01.00 201-229-111)
          with ESMTP
          id <19990602221632.ZMUH13307.mail.rdc1.sfba.home.com@c62443-a.frmt1.sfba.home.com>;
          Wed, 2 Jun 1999 15:16:32 -0700
Received: (from adsharma@localhost)
	by c62443-a.frmt1.sfba.home.com (8.8.7/8.8.7) id PAA30965;
	Wed, 2 Jun 1999 15:16:31 -0700
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>
References: <199906021816.LAA14736@lestat.nas.nasa.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.1i
In-Reply-To: <199906021816.LAA14736@lestat.nas.nasa.gov>; from Jason Thorpe on Wed, Jun 02, 1999 at 11:16:32AM -0700
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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