tech-kern archive

[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.


Home | Main Index | Thread Index | Old Index