From owner-freebsd-questions  Thu May 16 07:40:37 1996
Return-Path: owner-questions
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id HAA08482
          for questions-outgoing; Thu, 16 May 1996 07:40:37 -0700 (PDT)
Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA08476
          for <questions@FreeBSD.org>; Thu, 16 May 1996 07:40:29 -0700 (PDT)
Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id JAA13624; Thu, 16 May 1996 09:36:55 -0500 (EST)
From: "John S. Dyson" <toor@dyson.iquest.net>
Message-Id: <199605161436.JAA13624@dyson.iquest.net>
Subject: Re: Size of the Virtual Memory Page
To: luigi@labinfo.iet.unipi.it (Luigi Rizzo)
Date: Thu, 16 May 1996 09:36:55 -0500 (EST)
Cc: toor@dyson.iquest.net, alc@cs.rice.edu, questions@FreeBSD.org
In-Reply-To: <199605160823.KAA04249@labinfo.iet.unipi.it> from "Luigi Rizzo" at May 16, 96 10:23:22 am
Reply-To: dyson@FreeBSD.org
X-Mailer: ELM [version 2.4 PL24 ME8]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-questions@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> 
> [haven't seen yet the previous messages, but I assume the subject is
> using larger units of allocation for "pages"]
> 
> > > P.S.  Theoretically, you could do the same thing on the x86.  John (Dyson),
> > > have you ever thought of trying this just for grins?  Some stuff would likely
> > > break, but... :-)
> > > 
> > I have thought about it (in passing.)  Actually, it could decrease overhead in
> > some cases, at the expense of memory.  8/16K pages *might* be interesting.  The
> > VM and vfs_bio system (after my changes) will have problems with bigger than
> > 16K pages.  I am sure that they could be worked around.  The limitation
> > has to do with the bit-mask that I use for valid and dirtyness being in
> > 512 byte increments.  We have 32bits/word, so that means that 16K is kind
> 
> my curiosity is how/why do you use 512 byte-blocks: just to leave it
> open the use of different page sizes (and 512*8=4K, so a dirty x86 page
> just has a mark of 0xff) ?
> 
Because DEV_BSIZE is 512.  That is the incremental I/O size to/from a
block device.  Of course, some devices might be 1K -- but then that is
a multiple of DEV_BSIZE.  Remember, MSDOSFS has 512 Byte block sizes that
we have to deal with.  EXT2FS has 1K block sizes.  Not all filesystems
are as *nice* as FFS with a nice even multiple of a page size for a block
size.

John