From owner-freebsd-current  Thu Jul  8 14:14:59 1999
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2])
	by hub.freebsd.org (Postfix) with ESMTP id 7B0C914DA8
	for <freebsd-current@freebsd.org>; Thu,  8 Jul 1999 14:14:55 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id OAA42935;
	Thu, 8 Jul 1999 14:14:45 -0700 (PDT)
	(envelope-from dillon)
Date: Thu, 8 Jul 1999 14:14:45 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199907082114.OAA42935@apollo.backplane.com>
To: Peter Wemm <peter@netplex.com.au>
Cc: freebsd-current@freebsd.org
Subject: Re: current kernel build temporarily broken 
References:  <19990708194337.F02AE78@overcee.netplex.com.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

:>     it will crunch) at the moment.
:> 
:> 					-Matt
:
:Is there anything I can do? 
:
:Cheers,
:-Peter

    (CC'ing to current)

    Kirk committed the fix -- The sense of a KASSERT() had gotten reversed
    accidently.

    Everything is hunky dory - except for the fact that I'm not able to 
    commit any of these things myself.  The patches remaining in the current
    VFS/BIO set are relatively minor, which means I can shift my attention 
    over to the VM/INN/MMAP problems.  

    The INN problem is a stickier issue and the solution may wind up making
    -current slightly less efficient in the near term.  Basically what we
    have to do is to map writeable pages read-only and then take a fault
    to detect the clean->dirty transition.  We can then synchronously block
    in vm_fault (without holding any locks, I might add) when there are too 
    many dirty pages in the system.  The pageout daemon will be able to
    run earlier (before it becomes too late).

    Also, on the positive side, by accounting dirty pages earlier we can
    manage low-memory situations all that more easily, which means that we 
    can shift the clustering code from the beginning (when queued) to the
    end (when I/O is physically initiated).  This will have the side effect
    of removing a whole cartload of junk from the filesystem critical path
    as well as remove a bunch of fields from the vnode structure.  It will
    also greatly reduce the amount of memory-related blocking that occurs deep
    within a call-stack which should help performance on loaded machines
    by reducing lock contention.

    So if people don't scream at me for the slightly less efficient page
    faulting I think we can make progress.

    Actually, I don't think the page faulting will be as bad as all that...
    the loss of efficiency occurs mostly in shared R+W mmaps, not so much
    with BSS extensions because those tend to take a fault anyway because
    they start out as zero-fill.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message