Date: Tue, 06 Jan 1998 00:55:48 -0800 From: David Greenman <dg@root.com> To: Julian Elischer <julian@whistle.com> Cc: "John S. Dyson" <toor@dyson.iquest.net>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-sys@FreeBSD.ORG Subject: Re: John's latest VM commit. Message-ID: <199801060855.AAA27188@implode.root.com> In-Reply-To: Your message of "Tue, 06 Jan 1998 00:12:15 PST." <Pine.BSF.3.95.980105235915.7998F-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> It would probably be a good thing to make all caching in our system VM object
>> based. Then buffers will degrade into a structure used to communicate with
>> I/O devices. I would not like to see the terrible mess that SVR4 has, with
>> various types of vnode like structures in order to represent swap, filesystem,
>> device files.
>But every VM object needs an associated VNODE that represents the methods
>and data needed to access teh real backing store.
Actually, this isn't true. Most VM objects in the system are not vnode
objects and thus have no vnode associated with them. Most of the vnode
objects are actually containers for 'anonymous' memory that either has
no backing ('default pager') or is swap backed. It could be argued that
swap I/O should be done entirely differently and involve a vnode somehow,
but that would require a significant architectural change to the current
VM system - rewriting the swap pager and perhaps changing some of the
fundamental nature of the way that anonymous memory works. This might not
be such a bad thing, but it would be a major undertaking and I think the
result would yield little gain. ...'default pager' objects, which should
be the greatest percentage of objects in the system, have only in-memory
backing and are converted to swap objects at the first pageout. On systems
that don't page much, most objects in the system would remain default pager
objects for their lifetime. Since the vnode and object data structures
actually represent quite different things and have actually very little
overlap, it winds end up being very wasteful to merge them.
>> Eventually, as we can deprecate the use of buffer's as a metadata cache, I
>> think that our buffers will be able to be abstracted as I/O requests, as
>> they should be. Then, the more general VM objects will be the primary (only)
>> caching mechanism.
>
>so where does the metadata live?
Some of it (directories) lives in malloced memory that is attached to a
buffer. John did it this way because most directories are small (512-1K
bytes) and using a whole VM page (4K) was too wastefull.
-DG
David Greenman
Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801060855.AAA27188>