From owner-cvs-src@FreeBSD.ORG Sun Oct 26 00:45:49 2003 Return-Path: Delivered-To: cvs-src@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) Message-Id: <200310260745.h9Q7jVeF020616@gw.catspoiler.org> Date: Sun, 26 Oct 2003 00:45:31 -0700 (PDT) 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 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-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 07:45:49 -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.