Bug#594923: noflushd: Noflushd causes flush- processes to eat all CPU

[Jonathan Nieder <jrnieder@gmail.com>]

tags 594923 + patch moreinfo
quit

Hi,

Jonathan Nieder wrote:
> Daniel Kobras wrote:

>> now I can
>> reproduce the problem. It's not the fsync(), actually, but but the stopping of
>> the pdflush daemon that makes the flush-<major>:<minor> kernel threads enter a
>> busy loop (spinning in bdi_writeback_task()). It can be triggered as simple as:
>>
>>	echo 0 > /proc/sys/vm/dirty_writeback_centisecs
>>
>> (Use echo 500 > /proc/sys/vm/dirty_writeback_centisecs to restore a sane
>> behaviour.) Suspending pdflush activity this way used to work before. Now it
>> seems to be interpreted as a zero wait time between iterations in the flush
>> threads. Thus, I'd say this is a regression in the kernel.
[...]
> It seems to have been fixed in sid by the combination of commits
>
> - v2.6.35-rc1~442^2~17 (writeback: fixups for !dirty_writeback_centisecs,
>   2010-05-21)
> - v2.6.35-rc1~442^2~56 (writeback: disable periodic old data writeback
>   for !dirty_writeback_centisecs, 2010-05-17)
>
> The latter of the two was cherry-picked as part of v2.6.32.16.  (Maybe
> the regression was introduced by v2.6.32-rc1~733^2~4, "writeback:
> switch to per-bdi threads for flushing data", 2009-09-09.)

Ping.  Did you get a chance to try the latest kernel from squeeze?