From owner-cvs-src@FreeBSD.ORG Sun Oct 26 13:54:52 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 4263A16A4B3; Sun, 26 Oct 2003 13:54:52 -0800 (PST) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49F7F43FDD; Sun, 26 Oct 2003 13:54:49 -0800 (PST) (envelope-from alc@cs.rice.edu) Received: from localhost (localhost [127.0.0.1]) by cs.rice.edu (Postfix) with ESMTP id C63FD4AA29; Sun, 26 Oct 2003 15:54:48 -0600 (CST) 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 11715-01-4; Sun, 26 Oct 2003 15:54:47 -0600 (CST) Received: by cs.rice.edu (Postfix, from userid 19572) id 1AA8E4AA09; Sun, 26 Oct 2003 15:54:47 -0600 (CST) Date: Sun, 26 Oct 2003 15:54:46 -0600 From: Alan Cox To: Don Lewis Message-ID: <20031026215446.GD20658@cs.rice.edu> References: <20031026041909.GY20658@cs.rice.edu> <200310260745.h9Q7jVeF020616@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310260745.h9Q7jVeF020616@gw.catspoiler.org> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by amavis-20030616-p5 at rice.edu 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 21:54:52 -0000 On Sun, Oct 26, 2003 at 12:45:31AM -0700, Don Lewis wrote: > > 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. You could. My thoughts are: - Preemption encourages you, the kernel developer, to distinguish between what is shared and what is thread private, as opposed to what is shared and what is CPU private. The distinction between thread private and CPU private only matters when you're dealing with low-level state such as TLBs. - The switchin mechanism is very simple to implement and use. Setup and shutdown are two assignment statements. The overhead on a context switch is a conditional branch. I don't think what you propose has any less overhead. - I expect, however, that our scheduler(s) will someday support what you propose. - Most of the overhead in pmap_zero_page() stems from the use of a single, shared KVA. A mapping using that KVA is thread private, hence the use of the switchin mechanism to avoid IPIs for TLB shootdown, but the KVA itself is shared, hence the use of a mutex to control access to it. - I would rather see us eliminate the mutex by developing a low- overhead scheme for allocating temporary KVA. This scheme, like the switchin mechanism, has many possible uses throughout the kernel, both for thread private and shared mappings. In fact, this scheme might itself be implemented using CPU private data for efficiency. That's ok as far as I'm concerned because we've then encapsulated the aspects of managing CPU private stuff behind one general-purpose API, rather than having it pop up in pmap_zero_page(), SMP optimized pipes, etc. Regards, Alan