From owner-cvs-sys Fri Apr 17 23:26:41 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA11276 for cvs-sys-outgoing; Fri, 17 Apr 1998 23:26:41 -0700 (PDT) (envelope-from owner-cvs-sys) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA11245; Sat, 18 Apr 1998 06:26:35 GMT (envelope-from peter@FreeBSD.org) From: Peter Wemm Received: (from peter@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id XAA14791; Fri, 17 Apr 1998 23:26:17 -0700 (PDT) Date: Fri, 17 Apr 1998 23:26:17 -0700 (PDT) Message-Id: <199804180626.XAA14791@freefall.freebsd.org> To: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-sys@FreeBSD.ORG Subject: cvs commit: src/sys/kern vfs_subr.c Sender: owner-cvs-sys@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 1998/04/17 23:26:17 PDT Modified files: sys/kern vfs_subr.c Log: In vfs_msync(), test to see if the vnode being examined is "interesting" (ie: it has a vm_object attached and is marked as OBJ_MIGHTBEDIRTY) before attempting to lock it. This should reduce the cpu hit that is incurred when doing a sync(2) and when the syncer process is doing the 30-second writeback of dirty mmap() data to disk. Skip this speedup if we are doing an unmount() to be sure to get everything - we can afford to occasionally miss a msync while the system is running, but not at unmount. I'm not sure about the VXLOCK and MNT_WAIT case, it seems a bit odd to skip doing a page_clean at unmount time just because a vnode is VXLOCKed, but that's what was being done before... Revision Changes Path 1.151 +10 -3 src/sys/kern/vfs_subr.c