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? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org