Date: Tue, 18 Dec 2007 17:20:30 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: David G Lawrence <dg@dglawrence.com> Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Packet loss every 30.999 seconds Message-ID: <20071218170133.X32807@delplex.bde.org> In-Reply-To: <20071217103936.GR25053@tnn.dglawrence.com> References: <D50B5BA8-5A80-4370-8F20-6B3A531C2E9B@eng.oar.net> <20071217103936.GR25053@tnn.dglawrence.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 17 Dec 2007, David G Lawrence wrote:
> One more comment on my last email... The patch that I included is not
> meant as a real fix - it is just a bandaid. The real problem appears to
> be that a very large number of vnodes (all of them?) are getting synced
> (i.e. calling ffs_syncvnode()) every time. This should normally only
> happen for dirty vnodes. I suspect that something is broken with this
> check:
>
> if (vp->v_type == VNON || ((ip->i_flag &
> (IN_ACCESS | IN_CHANGE | IN_MODIFIED | IN_UPDATE)) == 0 &&
> vp->v_bufobj.bo_dirty.bv_cnt == 0)) {
> VI_UNLOCK(vp);
> continue;
> }
Isn't it just the O(N) algorithm with N quite large? Under ~5.2, on
a 2.2GHz A64 UP in 32-bit mode, I see a latency of 3 ms for 17500 vnodes,
which would be explained by the above (and the VI_LOCK() and loop
overhead) taking 171 ns per vnode. I would expect it to take more like
20 ns per vnode for UP and 60 for SMP.
The comment before this code shows that the problem is known, and says
that a subroutine call cannot be afforded unless there is work to do,
but the, the locking accesses look like subroutine calls, have subroutine
calls in their internals, and take longer than simple subroutine calls
in the SMP case even when they don't make subroutine calls. (IIRC, on
A64 a minimal subroutine call takes 4 cycles while a minimal locked
instructions takes 18 cycles; subroutine calls are only slow when their
branches are mispredicted.)
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071218170133.X32807>