Bug 13583 - pdflush uses 5% CPU on otherwise idle system
Summary: pdflush uses 5% CPU on otherwise idle system
Alias: None
Product: IO/Storage
Classification: Unclassified
Component: Block Layer (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jens Axboe
Depends on:
Blocks: 13070
  Show dependency tree
Reported: 2009-06-19 13:33 UTC by Paul Martin
Modified: 2012-06-08 15:25 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.30
Regression: Yes
Bisected commit-id:

opreport -d output (35.33 KB, text/plain)
2009-06-19 22:41 UTC, Paul Martin
/proc/meminfo contents (1.01 KB, text/plain)
2009-06-19 22:42 UTC, Paul Martin
opreport from (1.83 KB, text/plain)
2009-07-28 09:45 UTC, Oskar Wróbel

Description Paul Martin 2009-06-19 13:33:04 UTC
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.
Comment 1 Jens Axboe 2009-06-19 18:41:52 UTC
Sounds odd. You should try and run eg oprofile to see where it's spending that time. Also attach /proc/meminfo.
Comment 2 Paul Martin 2009-06-19 22:41:45 UTC
Created attachment 22016 [details]
opreport -d output
Comment 3 Paul Martin 2009-06-19 22:42:15 UTC
Created attachment 22017 [details]
/proc/meminfo contents
Comment 4 Andrew Morton 2009-06-29 21:41:15 UTC
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?
Comment 5 Paul Martin 2009-07-05 11:23:24 UTC
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?
Comment 6 Oskar Wróbel 2009-07-28 09:40:24 UTC
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).
Comment 7 Oskar Wróbel 2009-07-28 09:45:21 UTC
Created attachment 22517 [details]
opreport from
Comment 8 hydrologiccycle 2009-11-15 23:57:28 UTC
This is also a problem with  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.
Comment 9 Alan 2012-06-08 15:25:39 UTC
Closing as obsolete, if this is incorrect please re-open and update the kernel version to a recent one

Note You need to log in before you can comment on or make changes to this bug.