Date: Mon, 23 Dec 1996 22:52:09 -0800 From: David Greenman <dg@root.com> To: Peter Wemm <peter@spinner.dialix.com> Cc: Erich Boleyn <erich@uruk.org>, smp@freebsd.org, haertel@ichips.intel.com, wscott@ichips.intel.com Subject: Re: I think we have the culprit!! (was -> Re: Eureka (maybe...) (was -> Re: P6 problem idea ) ) Message-ID: <199612240652.WAA27742@root.com> In-Reply-To: Your message of "Tue, 24 Dec 1996 14:00:46 %2B0800." <199612240600.OAA19697@spinner.DIALix.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
>On the standard kernel when on a cpu_class >= PPro (not Pentium) we set >the PG_G bits. Actually, it is conditional on the "PGE" chip feature...it doesn't matter if it is a P5 or P6. > We also have an invltlb() function call as well as the >page level invlpg() and invl2pg() calls. (invl2pg just does two invlpg's >in a single function call to lower the function call overheads). > >On the SMP kernel, all three of these functions cause an "global >invalidate" broadcast. If the initiating cpu is actually trying to modify >a PG_G page, this will screw up since the per-page invalidate gets >converted to a global invalidate on the other cpu's, and hence they don't >flush their PG_G page. > >Does that sound like a plausable explanation? That's what we've talking about... >If so, we need to refine the implementation of TLB shootdowns more so that >we can initiate a per-page flush as well as a global flush.. This will >require syncronisation, so if you can send your code you can save some >reinvention.. :-) Uh, no, I don't think that is the right solution. The single-page invalidates are going to be too expensive in the SMP case. I think a better solution would be to simply only set the PG_G flag for static mappings (kernel text, data, and bss), and NOT set it for other kernel mappings if SMP is true. This is a trivial change to pmap.c. >> I might be confused here, but as mentioned in the above comment, I >> thought this was implemented in the Pentium as well. Can someone >> who remembers better (or has the "Appendix H" equivalent released >> documentation) comment? > >Don't know about the Pentium, but we definately don't enable it on >anything smaller than a PPro. See above. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612240652.WAA27742>