Date: Sat, 25 Oct 2003 23:19:09 -0500 From: Alan Cox <alc@cs.rice.edu> To: Jeff Roberson <jroberson@chesapeake.net> Cc: Peter Wemm <peter@wemm.org> Subject: Re: cvs commit: src/sys/i386/i386 pmap.c Message-ID: <20031026041909.GY20658@cs.rice.edu> In-Reply-To: <20031025231217.B43805-100000@mail.chesapeake.net> References: <20031025230711.B20F92A7EA@canning.wemm.org> <20031025231217.B43805-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 25, 2003 at 11:14:48PM -0400, Jeff Roberson wrote: > > Uhm, dumb question, why don't we just allocate one page of kva per > processor and avoid the mutex, the switchin/out, etc? To save KVA? At 3 > pages per processor and a max of 8 processors on intel, that's 192k. We > can probably spare it. I just saved that much with some UMA tuning. > The mutex and the switchin mechanism are addressing two distinct needs. The mutex exists because there is a single KVA for some low-level pmap functions on i386. (This could be changed, eliminating the need for the mutex.) If, however, you eliminate the need for the mutex, you still require the switchin mechanism as a means of handling preemption, specifically, migration of the preempted thread between CPUs. The alternative is to make pmap_zero_page() and the like critical sections. In short, preemption and per-processor anything don't mix well. Looking into the future, I see other uses for the switchin mechanism when we begin optimizing in earnest. For example, in the context of pipes, if we move the pmap_qenter() from the sending side to the receiving side (just before the copy), the mapping becomes thread private, just like the mapping in pmap_zero_page(). Consequently, the IPI on SMPs for TLB shootdown could be eliminated. Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031026041909.GY20658>