From owner-freebsd-current@FreeBSD.ORG Wed Apr 28 21:31:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A6E616A4CE; Wed, 28 Apr 2004 21:31:03 -0700 (PDT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 500FF43D4C; Wed, 28 Apr 2004 21:31:03 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: from localhost (calypso.cs.rice.edu [128.42.1.127]) by cs.rice.edu (Postfix) with ESMTP id 0B3E44ACE6; Wed, 28 Apr 2004 23:31:03 -0500 (CDT) Received: from cs.rice.edu ([128.42.1.30]) by localhost (calypso.cs.rice.edu [128.42.1.127]) (amavisd-new, port 10024) with LMTP id 16610-01-10; Wed, 28 Apr 2004 23:31:02 -0500 (CDT) Received: by cs.rice.edu (Postfix, from userid 19572) id ACDDF4ACEC; Wed, 28 Apr 2004 23:31:02 -0500 (CDT) Date: Wed, 28 Apr 2004 23:31:02 -0500 From: Alan Cox To: Brian Fundakowski Feldman Message-ID: <20040429043102.GN5199@cs.rice.edu> References: <20040429022401.GJ5199@cs.rice.edu> <200404290305.i3T35CW6001661@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404290305.i3T35CW6001661@green.homeunix.org> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavis-20030616-p7 at cs.rice.edu cc: alc@FreeBSD.org cc: bms@FreeBSD.org cc: current@FreeBSD.org Subject: Re: VM wiring fixed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2004 04:31:03 -0000 On Wed, Apr 28, 2004 at 11:05:12PM -0400, Brian Fundakowski Feldman wrote: > Alan Cox wrote: > > On Wed, Apr 28, 2004 at 08:08:17PM -0400, Brian Fundakowski Feldman wrote: > > > There are several severe wiring bugs in -CURRENT that I believe I have fixed. > > > Please test/review as appropriate if you're affected by any of them. This > > > is a superset of the previous patch which just mostly-fixed mlockall(2). > > > > > > * MAP_FUTUREWIRE was not unset in vmspace_dofree(), causing the next process > > > to use that vmspace to wire all of its memory. > > > > Would setting flags to 0 in vmspace_alloc() accomplish the same? > > Yeah, same deal, except since we're optimizing by only clearing/ > reinitializing some fields for the vmspace-zone objects, it makes a little > more sense IMO to have it in the vmspace_dofree(). > To be honest, I would prefer to see this done by initializing flags to zero in vmspace_alloc(). I don't see how setting a field to zero at allocation time is less efficient than calling static __inline void vm_map_modflags(vm_map_t map, vm_flags_t set, vm_flags_t clear) { map->flags = (map->flags | set) & ~clear; } at deallocation time. In fact, I would expect initializing the field to zero at initialization time to be faster. It is also the more conventional and conservative approach. (For example, it would protect us from a future change to UMA such that the pages used to fill a zone are no longer prezeroed.) I'll follow up on the other questions later. I would encourage you to go ahead and commit the fix to flags. Regards, Alan