On Tue, May 11, 2010 at 10:41 PM, James Cameron <[email protected]> wrote: > Yes, significantly. What I've observed is most likely entirely due to > vm.dirty_* behaviour.
Interesting! There was discussion on the kernel list (reported on lwn iirc) about how to tweak this to improve behaviour under heavy write scenarios... instead of panicking every expire_centisecs (or when the buffer fills up) and stalling horribly, the kernel should start writing to disk a bit earlier and hopefully fast enough to avoid or minimise the ugly stalls. ... > causes the dd to finish in 7 seconds instead of 92 seconds, the sync to > take much longer, and the write latencies are much smaller. That's what I meant -- "fixing" this with larger values causes the kernel to choke later, for longer. Others can paper over this with gobs of RAM or faster disks... not us. I can't remember the outcome of that discussion -- but might be worth re-visiting. Recording video on our hardware (inc class 2 sd cards) surely needs the kernel to behave well. [ some googling ensues... ] Cannot find the right lwn article, but I think setting dirty_background_ratio and dirty_background_bytes should help in kicking the kernel into action earlier, possibly avoiding the stall. The relevant patch (landed in 2.9.29) has a good commit msg: http://lkml.org/lkml/2008/11/23/160 m -- [email protected] [email protected] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
