Date: Mon, 23 Dec 1996 23:40:35 -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: <199612240740.XAA27949@root.com> In-Reply-To: Your message of "Tue, 24 Dec 1996 15:17:37 %2B0800." <199612240717.PAA00923@spinner.DIALix.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
>David Greenman wrote: >> >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. > >What I had in mind was simply storing up to the two addresses. When the >IPI handler on the slave CPU fires, it checks the first address. If it's >zero, it does a global invalidate and returns. If it's set it does an >invlpg on the address. If the second one is set, it does an invlpg on that >one too. The cost of doing this relative to the cost of the IPI in the >first place should be pretty small since it's just a few extra >instructions. How expensive are global unnecessary TLB refills? In the case where the single-page invalidates are only happening once (not in a loop - pmap_kremove()), then this would be a win. In the other case where many pages will be singularly invalidated (pmap_qremove), it would be a lose. I think that in our current code, pmap_kenter's are always paired with pmap_kremove's, and pmap_qenter's are always paired with pmap_qremove's, but it is probably a bad assumption to assume this will always be true...so I'm a little uncomfortable with splitting the behavior (PG_G in one case, not in the other). -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?199612240740.XAA27949>