[lkml]   [2006]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Page writeback broken after resume: wb_timer lost
    Mark Lord wrote:
    > Johannes Stezenbach wrote:
    >> On Sat, May 20, 2006, Andrew Morton wrote:
    >>> From: Andrew Morton <>
    >>> pdflush is carefully designed to ensure that all wakeups have some
    >>> corresponding work to do - if a woken-up pdflush thread discovers
    >>> that it
    >>> hasn't been given any work to do then this is considered an error.
    >>> That all broke when swsusp came along - because a timer-delivered
    >>> wakeup to a
    >>> frozen pdflush thread will just get lost. This causes the pdflush
    >>> thread to
    >>> get lost as well: the writeback timer is supposed to be re-armed by
    >>> pdflush in
    >>> process context, but pdflush doesn't execute the callout which does
    >>> this.
    >>> Fix that up by ignoring the return value from try_to_freeze(): jsut
    >>> proceed,
    >>> see if we have any work pending and only go back to sleep if that is
    >>> not the
    >>> case.
    >>> Signed-off-by: Andrew Morton <>
    >> I've tested this patch for about a week now, by applying it to
    >> the 2.6.17-rc3 kernel on my laptop, which I've been using
    >> for more than a month now. This patch seems to cure the
    >> mysterious symptoms reported in February:
    >> etc.
    >> Actually I didn't remember to check "Dirty:" in /proc/meminfo,
    >> but when I "sync"ed at the end of my workday, just prior to
    >> swsupending it, sync returned immediately. with unpatched
    >> 2.6.17-rc3, sync would take half a minute
    > I just gave it a try here. With or without a suspend/resume cycle after
    > boot,
    > the "sync" time is much quicker. But the Dirty count in /proc/meminfo
    > still shows very huge (eg. 600MB) values that never really get smaller
    > until I type "sync". But that subsequent "sync" only takes a couple
    > of seconds now, rather than 10-20 seconds like before.

    Yup, behaviour is *definitely* much better now. I'm not sure why
    the /proc/meminfo "Dirty" count lags behind reality, but the disk
    is being kept much more up-to-date than without this patch.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-06-21 05:41    [W:0.022 / U:18.552 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site