From owner-freebsd-current@FreeBSD.ORG Thu May 20 12:47:38 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 B76B116A4CE; Thu, 20 May 2004 12:47:38 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7075F43D41; Thu, 20 May 2004 12:47:38 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <2004052019473701400j9node>; Thu, 20 May 2004 19:47:37 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA73762; Thu, 20 May 2004 12:47:36 -0700 (PDT) Date: Thu, 20 May 2004 12:47:34 -0700 (PDT) From: Julian Elischer To: Jake Burkholder In-Reply-To: <20040520041824.GA6503@locore.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Thomas Moestl cc: FreeBSD current users cc: sparc64@freebsd.org Subject: Re: sparc64 question.. Anyone out there? 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, 20 May 2004 19:47:38 -0000 Firstly, thanks for explaining this to me.. On Thu, 20 May 2004, Jake Burkholder wrote: > > > I'm not convinced that this is valid.. > > > consider.. > > > When you cycle through the processors above and remove the pointers to > > > the vmspace, then proceed to destroy this vmspace, there is nothing done > > > to make sure that the other procerssors are actually > > > not USING the page tables etc. associated with the vmspace. > > The reference count on the vmspace. > > > > > > > If we reclame the page tables.. surely there is a danger that another > > > cpu by still be using them? > > No because there is only one kernel page table and all cpus start using > it implicitly when they enter the kernel. So there are no other resources associated with a vmspace than the page table used at this point, and since they are using the special kernel page table instead, it doesn't matter if it goes away.. All that matters is that processors not try use it again if they are already in the kernel, and have a cached reverence to it.. I assume this is the scenario: processor 1 runs processA, then enters the kernel fo rsome reason becomes idle... processor 2 gets an interrupt and winds up continuing process A. processor 2 calls exit() from process A. processor 2 calls wait() from process C and frees the vm. processor 1 still has a reference to process A's vmspace which has been freed. Since the vmspace is still in existence until wait() is called, removing all the other references as should be safe. WHy does cpu_exit() not just do this work itself? Just because of the schedlock? All the architectures are calling a stub cpu_sched_exit() just for the sake of the sparc optimisation. DO you see this optimisation being eventually applied to other architectures? Thanks for your patience. >