From owner-cvs-all  Wed Mar  6 22: 9:51 2002
Delivered-To: cvs-all@freebsd.org
Received: from beppo.feral.com (beppo.feral.com [192.67.166.79])
	by hub.freebsd.org (Postfix) with ESMTP
	id 4B57E37B402; Wed,  6 Mar 2002 22:09:47 -0800 (PST)
Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1])
	by beppo.feral.com (8.11.3/8.11.3) with ESMTP id g2769kf36926;
	Wed, 6 Mar 2002 22:09:46 -0800 (PST)
	(envelope-from mjacob@feral.com)
Date: Wed, 6 Mar 2002 22:09:46 -0800 (PST)
From: Matthew Jacob <mjacob@feral.com>
X-Sender: mjacob@beppo
Reply-To: mjacob@feral.com
To: Jake Burkholder <jake@FreeBSD.org>
Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: Re: cvs commit: src/sys/sparc64/sparc64 pmap.c swtch.s
In-Reply-To: <200203070515.g275Fhi44253@freefall.freebsd.org>
Message-ID: <Pine.BSF.4.21.0203062208380.35833-100000@beppo>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
List-ID: <cvs-all.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20cvs-all>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20cvs-all>
X-Loop: FreeBSD.ORG


Hmm. Won't this lazy deactivation increase the expense of program startup when
you then actually have to do the tlb cleanup you had deferred? 

Wouldn't this be an ideal candidate for idle thread cleanup?

-matt


On Wed, 6 Mar 2002, Jake Burkholder wrote:

> jake        2002/03/06 21:15:43 PST
> 
>   Modified files:
>     sys/sparc64/sparc64  pmap.c swtch.s 
>   Log:
>   Implement kthread context stealing.  This is a bit of a misnomer because
>   the context is not actually stolen, as it would be for i386.  Instead of
>   deactivating a user vmspace immediately when switching out, and recycling
>   its tlb context, wait until the next context switch to a different user
>   vmspace.  In this way we can switch from a user process to any number of
>   kernel threads and back to the same user process again, without losing any
>   of its mappings in the tlb that would not already be knocked by the automatic
>   replacement algorithm.  This is not expected to have a measurable performance
>   improvement on the machines we currently run on, but it sounds cool and makes
>   the sparc64 port SMPng buzz word compliant.
>   
>   Revision  Changes    Path
>   1.38      +1 -0      src/sys/sparc64/sparc64/pmap.c
>   1.18      +26 -27    src/sys/sparc64/sparc64/swtch.s
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message