Date: Sat, 14 Dec 1996 11:02:08 -0800 From: Erich Boleyn <erich@uruk.org> To: haertel@ichips.intel.com Cc: smp@freebsd.org, dg@root.com Subject: Re: some questions concerning TLB shootdowns in FreeBSD Message-ID: <E0vYzLc-0004xo-00@uruk.org> 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
haertel@ichips.intel.com (Mike Haertel) writes: > >I'm still digesting it, I am almost worried that we might (shudder!) > >be forced into doing an IPI to stop all the cpu's *before* the > >current cpu changes the page tables, then letting them do the tlb > >flush and letting them proceed. If this actually is a real problem > >this means a much bigger code impact. > > You must do precisely this. > > The x86 architecture includes some complex instructions that > reference the same memory locations more than once--read-modify-write > sequences are the most obvious example. For various reasons, > there is no guarantee that the TLB entries associated with those > memory locations are locked in the TLB, and so they might be > thrashed out due to other activity while those complex instructions > are executing. If, in the meantime, some other processor > has manipulated the associated PTE in any way that lowers privilege > or changes the mapping, this processor could get a page fault > in a *non restartable* way, since it would see the mapping and/or > privilege changing under foot, but have already committed to > finishing the instruction (since the privilege checks are > normally only done at the beginning of the instruction). Urk! Thanks for clarifying this. I'm curious as to why this hasn't been a problem on Linux-SMP ... -- Erich Stefan Boleyn \_ E-mail (preferred): <erich@uruk.org> Mad Genius wanna-be, CyberMuffin \__ (finger me for other stats) Web: http://www.uruk.org/~erich/ Motto: "I'll live forever or die trying"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0vYzLc-0004xo-00>