From owner-freebsd-current@FreeBSD.ORG  Wed May 19 21:19:04 2004
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 F114D16A4CE; Wed, 19 May 2004 21:19:03 -0700 (PDT)
Received: from k6.locore.ca (k6.locore.ca [216.58.85.247])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 7DB3F43D2F; Wed, 19 May 2004 21:19:03 -0700 (PDT)
	(envelope-from jake@locore.ca)
Received: by k6.locore.ca (Postfix, from userid 1000)
	id 9AF46A923; Thu, 20 May 2004 00:18:24 -0400 (EDT)
Date: Thu, 20 May 2004 00:18:24 -0400
From: Jake Burkholder <jake@locore.ca>
To: Julian Elischer <julian@elischer.org>
Message-ID: <20040520041824.GA6503@locore.ca>
References: <Pine.BSF.4.21.0405181248180.41838-100000@InterJet.elischer.org>
	<Pine.BSF.4.21.0405191228190.41838-100000@InterJet.elischer.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.BSF.4.21.0405191228190.41838-100000@InterJet.elischer.org>
User-Agent: Mutt/1.4.2.1i
cc: Thomas Moestl <tmm@FreeBSD.org>
cc: FreeBSD current users <current@freebsd.org>
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
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 20 May 2004 04:19:04 -0000

> > 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.

Jake