From owner-cvs-all@FreeBSD.ORG Sat Oct 25 21:19:13 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F6F016A4B3; Sat, 25 Oct 2003 21:19:13 -0700 (PDT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93BA343F93; Sat, 25 Oct 2003 21:19:12 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: from localhost (localhost [127.0.0.1]) by cs.rice.edu (Postfix) with ESMTP id B645A4A9D0; Sat, 25 Oct 2003 23:19:11 -0500 (CDT) Received: from cs.rice.edu ([127.0.0.1]) by localhost (cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29892-01-79; Sat, 25 Oct 2003 23:19:09 -0500 (CDT) Received: by cs.rice.edu (Postfix, from userid 19572) id C2D3A4A9C2; Sat, 25 Oct 2003 23:19:09 -0500 (CDT) Date: Sat, 25 Oct 2003 23:19:09 -0500 From: Alan Cox To: Jeff Roberson Message-ID: <20031026041909.GY20658@cs.rice.edu> References: <20031025230711.B20F92A7EA@canning.wemm.org> <20031025231217.B43805-100000@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031025231217.B43805-100000@mail.chesapeake.net> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavis-20030616-p5 at rice.edu cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Peter Wemm Subject: Re: cvs commit: src/sys/i386/i386 pmap.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 04:19:13 -0000 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