Date: Thu, 29 Dec 2005 18:16:17 +0200 From: Diomidis Spinellis <dds@aueb.gr> To: Brian Fundakowski Feldman <green@FreeBSD.ORG> Cc: cvs-src@FreeBSD.ORG, src-committers@FreeBSD.ORG, Diomidis Spinellis <dds@FreeBSD.ORG>, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_exec.c vfs_subr.c src/sys/sys vnode.h src/sys/ufs/ufs ufs_vnops.c src/sys/vm vm_mmap.c Message-ID: <43B40BD1.7020400@aueb.gr> In-Reply-To: <20051229150819.GA27794@green.homeunix.org> References: <200512261347.jBQDlKUB022385@repoman.freebsd.org> <20051229150819.GA27794@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Brian Fundakowski Feldman wrote: > On Mon, Dec 26, 2005 at 01:47:20PM +0000, Diomidis Spinellis wrote: > >>dds 2005-12-26 13:47:20 UTC >> >> FreeBSD src repository >> >> Modified files: (Branch: RELENG_6) >> sys/kern kern_exec.c vfs_subr.c >> sys/sys vnode.h >> sys/ufs/ufs ufs_vnops.c >> sys/vm vm_mmap.c >> Log: >> MFC changes from 2005.10.26: >> Move execve's access time update functionality into a >> new vfs_mark_atime() function, and use the new function >> for performing efficient atime updates in mmap(). > > > Do you have any particular use cases that are improved a lot by > (seemingly) reducing gratuitous seeks for R/W file mappings? > Substantial improvement for the general case of not-noatime? > I have no comparative tests or use cases, because the base case was an earlier less-than-perfect change that only lived in HEAD for a week. The claimed "efficient atime updates in mmap()" are over an earlier change I committed to HEAD, but never MFCd (vm_mmap.c 1.202). I introduced that change to fix the behavior where reads through mmap(2)d files did not update the file's atime. As a result, for example, our implementation of cp(1) would copy files without updating the atime of the source. For that earlier change, bde@ complained: "This is a large pessimization for nfs and a usually-small pessimization for local file systems." The current implementation fixes that problem by following the existing approach in execve(2) (the then-named VA_EXECVE_ATIME flag), and is also cleaner than the earlier one. Diomidis
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43B40BD1.7020400>