Re: ioflush kernel thread chewing CPU time

[Andrew Doran <ad%netbsd.org@localhost>]

On Thu, Mar 19, 2009 at 10:21:49PM +1100, Simon Burge wrote:

> I've recently upgraded my dual CPU i386 laptop from a September 2008
> -current kernel to a netbsd-5 kernel from March 12.  I am using WAPBL on
> the four ffs filesystems.

What's the file system configuration? Do you have noatime, etc?
UFS1 or UFS1? Any especially active applications?

> After a couple of days, I noticed the system
> was really sluggish and found the ioflush kernel thread was using a
> lot of CPU time.  I've rebooted, and then another fews days later same
> issue.

What happens if you type `sync'? Can you try a gprof kernel? If you have
concurrent activity running, lockstat can sometimes give you a picture of
what is happening. I suggest putting in some counters to see what the syncer
is doing. For example:

- number VDIR vnodes flushed
- number VREG vnodes flushed
- number VT_VFS vnodes flushed (sync vnodes)

If you put an integer switch in the kernel you can turn the counters on at
runtime using gdb, when the problem starts to occur.
 
> Before I start digging, anyone else seen anything like this before? 

Nope. But, processing a sync vnode involves a trawl through all vnodes
associated with every file system. It sounds like that could be happening
too often, or for some reason perhaps vnodes on the worklist aren't getting
flushed.