Date: Wed, 13 Sep 2000 05:57:07 -0700 From: Julian Elischer <julian@elischer.org> To: Christopher Stein <stein@eecs.harvard.edu> Cc: Marius Bendiksen <mbendiks@eunet.no>, freebsd-fs@FreeBSD.ORG Subject: Re: how mmap buffer writes handled? Message-ID: <39BF79A3.2781E494@elischer.org> References: <Pine.OSF.4.20.0009122130450.13225-100000@wally>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39BF79A3.2781E494>