Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Dec 1996 11:20:40 +0900 (JST)
From:      Michael Hancock <michaelh@cet.co.jp>
To:        haertel@ichips.intel.com
Cc:        smp@freebsd.org
Subject:   Re: some questions concerning TLB shootdowns in FreeBSD
Message-ID:  <Pine.SV4.3.95.961217101015.527D-100000@parkplace.cet.co.jp>
In-Reply-To: <9612141725.AA57406@pdxcs078.intel.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 14 Dec 1996 haertel@ichips.intel.com wrote:

> 	1.  IPI to everyone sharing these specific PTE's
> 	2.  wait at barrier until everyone arrives
> 	3.  manipulate PTE
> 	4.  release barrier
> 	5.  everyone (including us) flushes TLB's

Here's SVR4.2/MP's algorithm for x86 from Unix Internals with terminology
translated to what we use: 

Initiator (Shooter)
-------------------

1. lock pmap
   acquire global spinlock to prevent other shootdowns

2. send IPI and wait for ack

3. modify ptes

4. increment counter

5. flush own tlb
   unlock global spinlock
   unlock pmap

Responder
---------

1. receive IPI

2. wait for counter to be incremented

3. flush own tlb


In SVR4.2/MP the hat (pmap) has a list of processors that the process
could be active on.

I don't know if we can make some of the same assumptions for optimizations
in FreeBSD, but we can probably find some later.

Places to look...

1) Look at all the FreeBSD events that cause tlbs and look for inherent
synchronization in the sequence.

2) Look at kernel vs. user tlb invalidations.  SVR4.2/MP can guarantee
that the kernel won't access an invalid tlb so can it can delay shootdowns
and hope that some other event such as a context switch will flush it
anyway.

3) Intel specific optimizations.  For example it has a level-1 (pointed to
by CR3/PDBR) page table containing ptes for level-2 tables.  In the
multiple pte case it can just invalidate appropriate entries in the
level-1 table.

The messages here have been leaving me in the dust, I'm sorry if I've said
something that's already been discussed.

Regards,


Mike




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.95.961217101015.527D-100000>