[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ioflush kernel thread chewing CPU time
On Mon, Mar 23, 2009 at 10:10:22PM +1100, Simon Burge wrote:
> > I've also just rebooted a kernel with your recent ffs_sync() change. I'll
> > let you know results in a day or two :-)
> With that change, I'm still seeing the same problem. Right now, ioflush
> is using about 21% CPU time according to top. With the same event
> counters above, over a 300 second window I see:
> - just before the while loop inside the for loop: 273
> - at the top of the while loop: 633
> - after vget success: 633
> type VDIR: 0
> type VREG: 499
> type VBLK: 0
> type VCHR: 0
> tag VFS: 134
> This time I have a firefox running that recently had some activity, so
> that might explain why we're seeing more activity in this 300 second
> window than we did before.
Ok, well the VREG ones aren't a big deal - that's only 500 files. The VFS
scans indicate that it's scanning thousands of vnodes a second through the
sync vnode (VFS_SYNC).
With the recent ffs changes sync vnodes are processed 3 times more often for
logging file systems: every 10 seconds, previously 30 seconds. It doesn't
seem like a big enough change to explain high CPU usage that starts after a
couple of days, and I don't see it on the two long-running systems that I
have with 5.0_RC on them: only one has logging, a slower older system.
I guess the answer lies in ffs_sync().
> Just to make sure, I'm running stock netbsd-5 with this patch:
That's the one, it _should_ flush out atime updates.
Main Index |
Thread Index |