Date: Tue, 16 Oct 2001 11:24:45 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Maxime Henrion <mux@qualys.com> Cc: freebsd-hackers@freebsd.org Subject: Re: cvs commit: src/sys/vm vnode_pager.c Message-ID: <200110161824.f9GIOjT33989@apollo.backplane.com> References: <xzpelo4r90f.fsf@flood.ping.uio.no> <200110152135.f9FLZpg56816@earth.backplane.com> <20011016172843.A469@nebula.cybercable.fr> <200110161618.f9GGIpM31430@apollo.backplane.com> <20011016190340.A465@nebula.cybercable.fr> <200110161712.f9GHCbg33501@apollo.backplane.com> <20011016194937.A447@nebula.cybercable.fr> <200110161757.f9GHv5633749@apollo.backplane.com> <20011016200300.B447@nebula.cybercable.fr> <200110161804.f9GI4wF33862@apollo.backplane.com> <20011016201014.C447@nebula.cybercable.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:Matthew Dillon wrote:
:>
:> The time jump is irrelevant. It's whether you feel a glitch or not
:> while the sync is running that counts.
:
:I don't do profiling on a sync command, I monitore the system with
:``iostat -w 1'' then I see where the jump occurs and since it occurs
:every 30s, I try to launch the profiling in a window around the jump as
:little as possible.
:
:Am I doing it wrong ?
:Maxime
Well, 11% over a period of a single second, once every 30 seconds
makes sense if there are a lot of vnodes cached. I think you are
seeing the same issue, just that on -stable there is much lower
overhead.
Basically we have two routines that are causing problems:
ffs_sync()
qsync() (quota sync)
The basic problem for both is that either a lock or a mutex
is being obtained and released for each loop. Actually two are
being obtained and two are being released for each loop.
The high level scan of the vnode list for the mount point only requires
one mutex to be held through the scan, so if we can flag the situation
somehow in a manner that can be detected without having to get the vnode
interlock, we can remove all in-loop lock/mutex operations for the
degenerate case.
We would still be scanning hundreds of thousands of vnodes, but at least
we would be scanning them in a tight loop without any subroutine calls..
maybe 15nS/loop instead of 500nS. That would solve the problem.
We can accomplish this for ffs_sync(). It's actually fairly easy to
do. Accomplishing this for qsync() is harder due to the many-to-one
relationship between inodes and their quota structures, and may require
a complete rewrite of the quota syncing code.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110161824.f9GIOjT33989>