From owner-freebsd-fs  Wed Sep 13  5:57:28 2000
Delivered-To: freebsd-fs@freebsd.org
Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231])
	by hub.freebsd.org (Postfix) with ESMTP id 57BB437B422
	for <freebsd-fs@FreeBSD.ORG>; Wed, 13 Sep 2000 05:57:24 -0700 (PDT)
Received: from muzak.iinet.net.au (muzak.iinet.net.au [203.59.24.237])
	by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id UAA18418;
	Wed, 13 Sep 2000 20:57:16 +0800
Received: from jules.elischer.org (reggae-12-112.nv.iinet.net.au [203.59.92.112])
	by muzak.iinet.net.au (8.8.5/8.8.5) with SMTP id UAA11114;
	Wed, 13 Sep 2000 20:57:13 +0800
Message-ID: <39BF79A3.2781E494@elischer.org>
Date: Wed, 13 Sep 2000 05:57:07 -0700
From: Julian Elischer <julian@elischer.org>
X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386)
MIME-Version: 1.0
To: Christopher Stein <stein@eecs.harvard.edu>
Cc: Marius Bendiksen <mbendiks@eunet.no>, freebsd-fs@FreeBSD.ORG
Subject: Re: how mmap buffer writes handled?
References: <Pine.OSF.4.20.0009122130450.13225-100000@wally>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-fs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Christopher Stein wrote:
> 
> I am aware of MMUs and COW-driven software emulation bits for
> architectures lacking them. You misinterpreted my concern. Or, more
> likely, I did not articulate it well enough. Here's another go:
> 
> The modified bits in the page table entries will be set as an
> mmapped buffer is dirtied by the application. Suppose this
> buffer is on the clean buffer queue rather than the dirty queue.
> How will it be transferred to the dirty queue, where it belongs?
> 
> If this is done by a periodic scan, then code like the buf_daemon
> are heavily dependent on the period of this scan to be responsive
> under mmap heavy workloads. That would be an interesting
> tuning issue. However, I can't find this comprehensive scan.


while buffers are clean they ar emarked read-only in hardware.
on first write, a fault is taken, which transfers it to the 
dirty queue.

> 
> vfs_setdirty() is something close - scanning through a buffers pages,
> setting its dirty interval, then setting the pte modified bits to clean so
> that pageout doesn't begin acting on this FS buffer's
> pages. vfs_set_dirty() itself is only called from bdwrite() and
> vfs_busy_pages(). This on its own is insufficient to correct statistics
> like numdirtybuffers and move a buffer sitting on vp->v_cleanblkhd to
> vp->v_dirtyblkhd.
> 
> thnx
> -Chris
> 
> On Wed, 13 Sep 2000, Marius Bendiksen wrote:
> 
> > > How are these data structures and statistics kept meaningful
> > > under mmapped workloads?
> >
> > Most architectures that have an MMU, such as the x86, have a bit in their
> > page tables or equivalent that will indicate whether a page has been
> > modified since the last time that bit was cleared. This can be sampled and
> > cleared in one go.
> >
> > On architectures lacking an MMU, I think the logical approach would be to
> > use some of the protection facilities or such to force an exception to be
> > raised when accessing the page for write, and updating the statistics
> > based on that.
> >
> > Marius
> >
> >
> >
> > To Unsubscribe: send mail to majordomo@FreeBSD.org
> > with "unsubscribe freebsd-fs" in the body of the message
> >
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-fs" in the body of the message

-- 
      __--_|\  Julian Elischer
     /       \ julian@elischer.org
    (   OZ    ) World tour 2000
---> X_.---._/  presently in:  Perth
            v


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