Date: Sat, 14 Dec 1996 17:22:22 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: phk@critter.tfs.com (Poul-Henning Kamp) Cc: dyson@freebsd.org, peter@spinner.dialix.com, smp@freebsd.org, haertel@ichips.intel.com Subject: Re: some questions concerning TLB shootdowns in FreeBSD Message-ID: <199612142222.RAA05499@dyson.iquest.net> In-Reply-To: <5557.850593988@critter.tfs.com> from "Poul-Henning Kamp" at Dec 14, 96 09:06:28 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The crucial thing, as far as I can see, is to find out >if< we need to > tell the other CPU's about this change to the pagetables. For a 2cpu > system the penalty of stopping the other CPU is still within bounds > of the reasonable, but stopping three CPUs needlessly is not a good idea. > > Is there any cheap way to keep a refcount (or bitmap) per vm-object so > we can see if we need to kick the other CPUs if we fiddle it ? > That would be tricky if we can freely reschedule processes on other cpu's... It would entail traversing the map for the process when the process is scheduled. Normally, there is also no notification when a page table entry is fetched into the TLB. Such notification can be arranged on the advanced X86 processors, but it doesn't appear to be a guaranteed type thing. How's about just making the inter-processor interrupt efficient? We can probably redo some of the vm/pmap interface to have larger grained pmap update operations also. I suggest that in the short term, that the code be made algorithmically correct with the stop-processor suggestion made earlier. Later on, we can improve on the algorithmically correct (but slightly slower code), and do the things to the vm/pmap interface to make things much more efficient. John dyson@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612142222.RAA05499>