Date: Tue, 26 Aug 2003 16:06:06 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: John Baldwin <jhb@FreeBSD.org> Subject: Re: cvs commit: src/sys/vm vm_page.h Message-ID: <20030826153925.J8860@gamplex.bde.org> In-Reply-To: <20030825190349.GC18841@ns1.xcllnt.net> References: <200308230624.h7N6O0bq088622@repoman.freebsd.org> <20030825190349.GC18841@ns1.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030826153925.J8860>