[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ioflush kernel thread chewing CPU time
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
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
Main Index |
Thread Index |