On Tue, Oct 30, 2007 at 07:49:41PM +0800, Fengguang Wu wrote: > > > It could be triggered by the more aggressive writeback behavior - the > > > new code will keep on retrying as long as there are dirty inodes pending. > > > > > > Florin, would you try the attached patches against 2.6.24-git? > > > They may generate big traffic of printk messages, but will help > > > debug the problem. > > > > I have updated to v2.6.24-rc1-334-g82798a1. After using my computer > > for two hours, I left the computer idle overnight. This morning, > > pdflushd is again consuming 25% of a CPU. I will try Fengguang's > > patches today. > > Thank you. > > Be sure to stop klogd ;-) > A `dmesg` will be sufficient for debugging.
I have added the patches and started a linux kernel compilation, and something really interesting happens. I run the build with the equivalent of "make -j3" and in a separate console I am watching the build with 'top'. The build consumes 98% of both CPUs. If I stop the output in the build console with "Ctrl-S", one core goes to idle, while the other is in 50% waiting, then goes to 75% waiting. When I resume the build with "Ctrl-Q", the build starts to use both CPUs at 98-99%. The NFS4 use was minimal, as I did not login with Gnome, but just logged on the console. Also, the CPU that is in 75% waiting state changes occasionally. 'Top' shows pdflush in D state, using 5-6% of CPU. Cheers, florin -- Bruce Schneier expects the Spanish Inquisition. http://geekz.co.uk/schneierfacts/fact/163
signature.asc
Description: Digital signature