From owner-cvs-all@FreeBSD.ORG Mon Nov 10 21:03:05 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 0F52816A4D0 for ; Mon, 10 Nov 2003 21:03:05 -0800 (PST) Received: from vette.gigo.com (vette.gigo.com [216.218.228.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82ECD43F85 for ; Mon, 10 Nov 2003 21:02:59 -0800 (PST) (envelope-from lioux@brturbo.com) Received: from 200.101.111.208 (200-101-111-208.bsace705.dsl.brasiltelecom.net.br [200.101.111.208]) by vette.gigo.com (Postfix) with ESMTP id 2003457BC for ; Mon, 10 Nov 2003 20:51:32 -0800 (PST) Received: (qmail 26720 invoked by uid 1001); 11 Nov 2003 04:07:34 -0000 Message-ID: <20031111040734.26719.qmail@exxodus.fedaykin.here> Received: (qmail 72276 invoked from network); 26 Oct 2003 07:47:34 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 26 Oct 2003 07:47:34 -0000 Received: from pop3.uol.com.br by localhost with POP3 (fetchmail-6.2.5) for lioux-freebsd@localhost (single-drop); Sun, 26 Oct 2003 05:47:12 -0200 (BRST) Received: from peart.uol.com.br (172.26.5.187) by mtauol7.mail.sys.intranet (5.1.071) id 3EDB5C0C01D6C1C7 for lioux-freebsd@uol.com.br; Sun, 26 Oct 2003 04:46:30 -0300 Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by storm13.uol.com.br (Postfix) with ESMTP id 1B3C38E37A for ; Sun, 26 Oct 2003 05:46:29 -0200 (BRST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 890FF56C8C for ; Sun, 26 Oct 2003 00:46:24 -0700 (PDT) (envelope-from owner-src-committers@FreeBSD.org) Received: by hub.freebsd.org (Postfix) id 9F5B016A524; Sun, 26 Oct 2003 00:46:21 -0700 (PDT) Delivered-To: lioux@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 538) id 5CF1816A4C0; Sun, 26 Oct 2003 00:46:20 -0700 (PDT) Delivered-To: src-committers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21D1E16A4B3; Sun, 26 Oct 2003 00:45:49 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B6A443FA3; Sun, 26 Oct 2003 00:45:48 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id h9Q7jVeF020616; Sun, 26 Oct 2003 00:45:36 -0700 (PDT) (envelope-from truckman@FreeBSD.org) From: Don Lewis To: alc@cs.rice.edu In-Reply-To: <20031026041909.GY20658@cs.rice.edu> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Sender: owner-src-committers@FreeBSD.org Precedence: bulk X-Loop: FreeBSD.ORG cc: jroberson@chesapeake.net cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: peter@wemm.org cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 pmap.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 11 Nov 2003 05:03:05 -0000 X-Original-Date: Sun, 26 Oct 2003 00:45:31 -0700 (PDT) X-List-Received-Date: Tue, 11 Nov 2003 05:03:05 -0000 On 25 Oct, Alan Cox wrote: > 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. Why not allow preemption, but just mark the thread as being ineligable for migration while it is executing pmap_zero_page() and similar bits of code? The thread might have to wait longer to get the CPU again after it was preempted, but so what.