Hi Daniel, Daniel Kobras wrote:
> I've updated my devel machine to the latest kernel version, and 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. Thanks. What version did you experience this on? Is it fixed in squeeze? 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.) Looking forward to your thoughts, Jonathan -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
