The second pdflush process is the top process in "top" output, varying between 3% and 6% CPU, even when no file system activity is happening, and this remains true after a forced "sync". This is a regression from 2.6.29.
Sounds odd. You should try and run eg oprofile to see where it's spending that time. Also attach /proc/meminfo.
Created attachment 22016 [details] opreport -d output
Created attachment 22017 [details] /proc/meminfo contents
That oprofile report is a bit hard to parse. I use opreport -l /boot/vmlinux-$(uname -r) | head -50 to generate a nice sorted list of the hottest functions. Can you do that please?
Sorry no oprofile report, but I have further information. Setting /proc/sys/vm/laptop_mode to 2 causes disc activity every two seconds, even if there's nothing to do. This is on xfs, so it might be that filesystem has changed behaviour. I notice that xfs has recently stopped using pdflush (commit 8b5403a6d772d340541cfb30a668fde119c40ac1). Could this be related?
I encountered similar bug with 2.6.28 to 2.6.30 kernels, but pdflush actually uses 100% (all available) cpu on my system. Also I can't sync or umount root partition on ext4 because of this. I will attach oprofiled report from 2.6.30 (with gentoo-patches, but it's mostly fbcondecor so it shouldn't matter).
Created attachment 22517 [details] opreport from 2.6.30.2
This is also a problem with 2.6.31.6. The problem with pdflush seems to relate to the version of gcc. If the kernel is built with gcc-4.3.4, then it will have this problem with pdflush. If the kernel is built with gcc-4.1.2, there is no problem.
Closing as obsolete, if this is incorrect please re-open and update the kernel version to a recent one