From owner-cvs-sys  Fri Apr 17 23:26:41 1998
Return-Path: <owner-cvs-sys>
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 <peter@FreeBSD.ORG>
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