From owner-cvs-src@FreeBSD.ORG Sun Apr 30 07:18:23 2006 Return-Path: X-Original-To: cvs-src@freebsd.org 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 A404C16A402; Sun, 30 Apr 2006 07:18:23 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0244643D48; Sun, 30 Apr 2006 07:18:22 +0000 (GMT) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail01.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id k3U7IIN5020516 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 30 Apr 2006 17:18:19 +1000 Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.13.6/8.13.6) with ESMTP id k3U7IIsV002278; Sun, 30 Apr 2006 17:18:18 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.13.6/8.13.6/Submit) id k3U7IHVt002277; Sun, 30 Apr 2006 17:18:17 +1000 (EST) (envelope-from peter) Date: Sun, 30 Apr 2006 17:18:17 +1000 From: Peter Jeremy To: Peter Wemm Message-ID: <20060430071817.GA980@turion.vk2pj.dyndns.org> References: <200604281905.k3SJ59MZ008806@repoman.freebsd.org> <20060429024850.GB997@turion.vk2pj.dyndns.org> <4452FB64.7030308@root.org> <200604291021.12379.peter@wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604291021.12379.peter@wemm.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.11 Cc: cvs-src@freebsd.org, src-committers@freebsd.org, ums@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/i386/i386 pmap.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Apr 2006 07:18:23 -0000 On Sat, 2006-Apr-29 10:21:11 -0700, Peter Wemm wrote: >In more detail. There is one PTE per page of virtual address space. It >is used by the hardware to translate a virtual address access to a >physical address. One normally stores the corresponding physical >address in there with various control bits (read/write mode etc) and >most importantly, the 'valid' (PG_V) bit. This tells the hardware of >the cpu that the physical address it found is valid. [etc] I'll second Julian's "request" that this comment be embedded in the code. >Stephan realized that the kernel already allocates one PTE per virtual >page. Although it normally holds physical addresses plus attributes, >as long as we don't set PG_V, then there are 31 other bits that we >could use for data storage. Intel mention that the top 31 bits are available to the OS if the bottom bit is zero in the 486 Programmers Reference Manual. >As long as the virtual addresses are page aligned, we neatly avoid all >the PG_* mode bits as well. We can avoid locking and atomic ops when >updating these because they are only accessed under the page queues >mutex. We can avoid doing pte invalidations (tlb shootdowns) because >there can never be any tlb entries corresponding to them. Nice piece of lateral thinking by Stephan and yourself. -- Peter Jeremy