From owner-cvs-all  Tue Dec 28  9:31:25 1999
Delivered-To: cvs-all@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 3858714DF7; Tue, 28 Dec 1999 09:31:19 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id JAA42073;
	Tue, 28 Dec 1999 09:31:18 -0800 (PST)
	(envelope-from dillon)
Date: Tue, 28 Dec 1999 09:31:18 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199912281731.JAA42073@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
References:  <199912280730.XAA04145@freefall.freebsd.org>
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

:  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