From owner-freebsd-current Sat Apr 15 20:13:28 2000 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 9643237B8A0; Sat, 15 Apr 2000 20:13:22 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA82143; Sat, 15 Apr 2000 20:13:20 -0700 (PDT) (envelope-from dillon) Date: Sat, 15 Apr 2000 20:13:20 -0700 (PDT) From: Matthew Dillon Message-Id: <200004160313.UAA82143@apollo.backplane.com> To: Alan Cox Cc: Brian Fundakowski Feldman , current@FreeBSD.ORG Subject: Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set. References: <20000415140945.B3462@cs.rice.edu> <20000415185718.E3462@cs.rice.edu> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Here's what I worry about: We only clear OBJ_ONEMAPPING on the top-level :object, and none of its backing objects. Nothing guarantees that these :backing objects have OBJ_ONEMAPPING cleared. The page that we're "double" :mapping may, however, reside in one of its backing objects. This is :bad. I don't think this is an issue. The only double-mapped pages we care about are those at the top-level (vm_object's connected directly to a vm_map_entry). This is because these are the only pages effected by write-faults and copy-on-write issues. For example, if you dirty a page that is mapped privately the system must copy-on-write the page. More importantly, if you fork() and either parent or child dirties what is now a shared page, they need to copy on write and the other process cannot see that change. OBJ_ONEMAPPING is an optimization that allows a process to dirty an anonymous (not vnode-backed) page without doing a copy-on-write in the case where that process is the ONLY process mapping the page. Copy-on-write is an issue that only effects the top level object. So we shouldn't care whether OBJ_ONEMAPPING is set or cleared in deeper objects. Copying a page that was previously shared is an expensive operation not only in having to do the copy, but also in having to split the vm_map_entry and create a new holding vm_object to hold the copy. This new object must have OBJ_ONEMAPPING set so that when pages are dirtied around it, it can be pre-pended or post-pended with the new pages rather then have to create a new vm_object (and thus not be able to coalesce the associated vm_map_entry structures) every time we take a copy-on-write fault. In this respect, the OBJ_ONEMAPPING optimization is *CRITICAL* to the scaleability of our VM system. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message