From owner-freebsd-smp  Sat Dec 14 13:25:39 1996
Return-Path: <owner-smp>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id NAA14411
          for smp-outgoing; Sat, 14 Dec 1996 13:25:39 -0800 (PST)
Received: from tfs.com (tfs.com [140.145.250.1])
          by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id NAA14404;
          Sat, 14 Dec 1996 13:25:32 -0800 (PST)
Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP
	id m0vZ1GT-0003wLC; Sat, 14 Dec 96 13:04 PST
Received: from critter.tfs.com (localhost [127.0.0.1]) by critter.tfs.com (8.8.2/8.8.2) with ESMTP id VAA05559; Sat, 14 Dec 1996 21:06:28 +0100 (MET)
To: dyson@freebsd.org
cc: peter@spinner.dialix.com (Peter Wemm), smp@freebsd.org,
        haertel@ichips.intel.com
Subject: Re: some questions concerning TLB shootdowns in FreeBSD 
In-reply-to: Your message of "Sat, 14 Dec 1996 13:38:47 EST."
             <199612141838.NAA00208@dyson.iquest.net> 
Date: Sat, 14 Dec 1996 21:06:28 +0100
Message-ID: <5557.850593988@critter.tfs.com>
From: Poul-Henning Kamp <phk@critter.tfs.com>
Sender: owner-smp@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In message <199612141838.NAA00208@dyson.iquest.net>, "John S. Dyson" writes:
>The way that I see it, is that the current pmap code is highly optimized
>for single processor operation.  If I was you, I would try to just
>try to get something working correctly algorithmically -- almost ignoring
>performance issues.  Of course, when performance is easy -- go for that
>also.
>
>Alot of things like single page invalidates inside of loops appear that
>they could be evil for multi-processor applications (imagine an inter-
>processor interrupt for every loop!?!?.)  I think that you (we or us),
>will have to look at the performance for the SMP direction, and it
>might even entail large differences in pmap eventually.  Hopefully,
>we will all be able to isolate the differences for the maintenance of
>sanity :-).

The crucial thing, as far as I can see, is to find out >if< we need to
tell the other CPU's about this change to the pagetables.  For a 2cpu
system the penalty of stopping the other CPU is still within bounds
of the reasonable, but stopping three CPUs needlessly is not a good idea.

Is there any cheap way to keep a refcount (or bitmap) per vm-object so
we can see if we need to kick the other CPUs if we fiddle it ?

--
Poul-Henning Kamp           | phk@FreeBSD.ORG       FreeBSD Core-team.
http://www.freebsd.org/~phk | phk@login.dknet.dk    Private mailbox.
whois: [PHK]                | phk@tfs.com           TRW Financial Systems, Inc.
Power and ignorance is a disgusting cocktail.