Date: Tue, 12 Sep 2000 21:51:59 -0400 (EDT) From: Christopher Stein <stein@eecs.harvard.edu> To: Marius Bendiksen <mbendiks@eunet.no> Cc: freebsd-fs@FreeBSD.ORG Subject: Re: how mmap buffer writes handled? Message-ID: <Pine.OSF.4.20.0009122130450.13225-100000@wally> In-Reply-To: <Pine.BSF.4.05.10009130324160.85482-100000@login-1.eunet.no>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.4.20.0009122130450.13225-100000>