From owner-cvs-src@FreeBSD.ORG Mon Aug 25 23:06:16 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 9B19516A4BF; Mon, 25 Aug 2003 23:06:16 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id A69A443FDF; Mon, 25 Aug 2003 23:06:14 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id QAA29179; Tue, 26 Aug 2003 16:06:08 +1000 Date: Tue, 26 Aug 2003 16:06:06 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Marcel Moolenaar In-Reply-To: <20030825190349.GC18841@ns1.xcllnt.net> Message-ID: <20030826153925.J8860@gamplex.bde.org> References: <200308230624.h7N6O0bq088622@repoman.freebsd.org> <20030825190349.GC18841@ns1.xcllnt.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: John Baldwin Subject: Re: cvs commit: src/sys/vm vm_page.h 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: Tue, 26 Aug 2003 06:06:16 -0000 On Mon, 25 Aug 2003, Marcel Moolenaar wrote: > On Mon, Aug 25, 2003 at 01:38:36PM -0400, John Baldwin wrote: > > > > On 23-Aug-2003 Marcel Moolenaar wrote: > > > marcel 2003/08/22 23:24:00 PDT > > > > > > FreeBSD src repository > > > > > > Modified files: > > > sys/vm vm_page.h > > > Log: > > > Add support for 16K and 32K page sizes. The valid and dirty maps > > > in struct vm_page are defined as u_int for 16K pages and u_long > > > for 32K pages, with the implied assumption that long will at least > > > be 64 bits wide on platforms where we support 32K pages. > > > > Why not use 'uint32_t' and 'uint64_t' to remove the assumption? Perhaps because it would be a pessimization for time if the fixed-width types are inefficient, and gratuitous breakage if the fixed-width types don't exist. (In practice, they should always exist, but might be very inefficient if the hardware doesn't support them directly.) Fixed-width types should only be used for laying out data structures in a fixed way. Anyway, there would still be an assumption that DEV_BSIZE is 512. > I thought about that but decided not to do it because it would > introduce a style variation that I considered worse than having > the implied assumption. There is still a minor style variation and space-pessimization. The old code makes some attempts to sort the fields on their size, as required in style(9) and as good for space efficiency, but the ifdefs get in the way of this and give very large fields near the end in some cases. The struct wasn't sorted very well in rev.1.1, but it was sorted in rev.1.11. Unsorting started in rev.1.40 with the initial version of the ifdefs to support 8K pages for alphas. This only affected systems with 8K pages. Unconditional unsorting started in rev.1.102 with the addition of the `cow' field at the end. Bruce