Date: Tue, 28 Dec 1999 09:31:18 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Wemm <peter@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/vm swap_pager.c vm_swap.c Message-ID: <199912281731.JAA42073@apollo.backplane.com> References: <199912280730.XAA04145@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
: This will need to be revisited when we swap to files (vnodes) - which
: is the other reason for keeping the vnode interface between the swap pager
: and the swap devices.
We are closer to being able to do this then you think! The same
vm_pager_strategy() stuff used to support swap backing store for the VN
device is actually an almost completely generalized extension to the
concept of a VM pager - it extends the VM pager subsystem by adding not
only a strategy call for vm_object pagers (for which we implemented the
one for OBJT_SWAP), but also by adding a vm_pager_page_unswapped() call
to tie into on-the-fly swap deallocation. I may have to add a
vm_pager_fork() entry point, but that should pretty much be it as far
as the design goes. We could then create an OBJT_FILESWAP VM object type
and use the newly extended VM pager API to implement it.
The swap subsystem's radix tree has also been designed to potentially
be operated in a dynamic fashion rather then static so we have the
choice of either assigning a file to each vm_object layer (which results
in creating a new file whenever you fork()), or managing swap within
a single file shared across many forks (which requires its own instance
of a radix tree for allocation management).
The VM pager extension is also designed (originally designed) to
eventually take over the I/O path for file I/O, replacing the VOP
subsystem's reading and writing functions and tying the I/O directly
into the vm_object, allowing us to do all sorts of very cool things.
But that is still a year away at best.
But we still have two significant problems: First we have a piecemeal
fragmentation problem if we use a file for backing store due to the way
UFS allocates blocks, and second we still have a number of low-memory
deadlock issues due to the extra non-deterministic allocation overhead
that occurs when writing to a file.
It's possible to simulate most of how a file-backed swap subsystem would
work by using mmap() with the new MAP_NOSYNC flag. The only things it
can't handle automatically would be fork() and deallocation of underlying
file blocks.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912281731.JAA42073>