Date: Sat, 14 Dec 1996 11:55:18 -0700 From: Steve Passe <smp@csn.net> To: haertel@ichips.intel.com Cc: peter@spinner.dialix.com, dg@root.com, smp@freebsd.org, toor@dyson.iquest.net Subject: Re: some questions concerning TLB shootdowns in FreeBSD Message-ID: <199612141855.LAA16724@clem.systemsix.com> In-Reply-To: Your message of "Sat, 14 Dec 1996 09:25:51 PST." <9612141725.AA57406@pdxcs078.intel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
>On multiprocessors, there is the additional concern of corrupting
>state which must remain invariant during instruction execution on
>other processors. So then you need the fully bulletproof code:
>
> 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
this was my concern but I didn't know how to word it so concisely! right
now the code looks like:
/* edited version to show the general idea: */
invlpg(u_int addr)
{
__asm __volatile("invlpg (%0)" : : "r" (addr) : "memory");
allButSelfIPI(ICU_OFFSET+27);
}
so some routine modifies a PTE, then calls invlpg(). this works for itself,
as it won't try to use the stale page between modifying the PTE and flushing
its TLB. However the other CPUs are running async, and may access the page
in question between the time the 1st CPU changes the PTE and the time they
receive the IPI. It seems like the rfork() situation where we seem to be
getting hit is particularily prone to tripping over this.
The above proposed algorithm seems like the only safe method of dealing
with the problem...
--
Steve Passe | powered by
smp@csn.net | FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612141855.LAA16724>