From owner-freebsd-smp  Sat Dec 14 14:22:32 1996
Return-Path: <owner-smp>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id OAA20923
          for smp-outgoing; Sat, 14 Dec 1996 14:22:32 -0800 (PST)
Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA20914;
          Sat, 14 Dec 1996 14:22:27 -0800 (PST)
Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id RAA05499; Sat, 14 Dec 1996 17:22:22 -0500 (EST)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199612142222.RAA05499@dyson.iquest.net>
Subject: Re: some questions concerning TLB shootdowns in FreeBSD
To: phk@critter.tfs.com (Poul-Henning Kamp)
Date: Sat, 14 Dec 1996 17:22:22 -0500 (EST)
Cc: dyson@freebsd.org, peter@spinner.dialix.com, smp@freebsd.org,
        haertel@ichips.intel.com
In-Reply-To: <5557.850593988@critter.tfs.com> from "Poul-Henning Kamp" at Dec 14, 96 09:06:28 pm
X-Mailer: ELM [version 2.4 PL24 ME8]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-smp@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 
> 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 ?
> 
That would be tricky if we can freely reschedule processes on other
cpu's...  It would entail traversing the map for the process when
the process is scheduled.  Normally, there is also no notification
when a page table entry is fetched into the TLB.  Such notification
can be arranged on the advanced X86 processors, but it doesn't
appear to be a guaranteed type thing.

How's about just making the inter-processor interrupt efficient?
We can probably redo some of the vm/pmap interface to have larger
grained pmap update operations also.

I suggest that in the short term, that the code be made algorithmically
correct with the stop-processor suggestion made earlier.  Later on,
we can improve on the algorithmically correct (but slightly slower code),
and do the things to the vm/pmap interface to make things much more efficient.

John
dyson@freebsd.org