Skip site navigation (1)Skip section navigation (2)
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>