Date: Thu, 16 May 1996 09:36:55 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: toor@dyson.iquest.net, alc@cs.rice.edu, questions@FreeBSD.org Subject: Re: Size of the Virtual Memory Page Message-ID: <199605161436.JAA13624@dyson.iquest.net> In-Reply-To: <199605160823.KAA04249@labinfo.iet.unipi.it> from "Luigi Rizzo" at May 16, 96 10:23:22 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605161436.JAA13624>