public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Lord <tigerdirect@rtr.ca>
To: Johannes Stezenbach <js@linuxtv.org>
Cc: Andrew Morton <akpm@osdl.org>, Pavel Machek <pavel@ucw.cz>,
	p.lundkvist@telia.com, linux-kernel@vger.kernel.org, rjw@sisk.pl,
	Mark Lord <lkml@rtr.ca>
Subject: Re: [PATCH] Page writeback broken after resume: wb_timer lost
Date: Mon, 19 Jun 2006 11:41:32 -0400	[thread overview]
Message-ID: <4496C5AC.3030809@rtr.ca> (raw)
In-Reply-To: <20060616212410.GA6821@linuxtv.org>

Johannes Stezenbach wrote:
> On Sat, May 20, 2006, Andrew Morton wrote:
>> From: Andrew Morton <akpm@osdl.org>
>>
>> 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 <akpm@osdl.org>
> 
> 
> 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:
> 
> http://lkml.org/lkml/2006/2/6/167
> http://lkml.org/lkml/2006/2/6/170
> http://lkml.org/lkml/2006/2/13/424
> 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. Maybe Mark can give
> this patch a spin to check if it cures his problem, too.
> (I still use vmware, so vmware was not the culprit.)

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.

Dunno what that all means -- I'm still keeping my little daemon around
to do periodic "sync" calls for safety.

Cheers

  parent reply	other threads:[~2006-06-19 15:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-20 13:03 [PATCH] Page writeback broken after resume: wb_timer lost Peter Lundkvist
2006-05-20 17:37 ` Andrew Morton
2006-05-20 22:50   ` Pavel Machek
2006-05-21  0:12     ` Andrew Morton
2006-05-21  6:52       ` Peter Lundkvist
2006-05-21 10:08       ` Pavel Machek
2006-06-16 21:24       ` Johannes Stezenbach
2006-06-16 23:12         ` Nigel Cunningham
2006-06-19 15:41         ` Mark Lord [this message]
2006-06-21  3:38           ` Mark Lord
2006-06-21  3:54             ` Andrew Morton
2006-06-21  4:10               ` Mark Lord
2006-06-21  4:19                 ` Andrew Morton
2006-06-22 20:25                   ` Mark Lord

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4496C5AC.3030809@rtr.ca \
    --to=tigerdirect@rtr.ca \
    --cc=akpm@osdl.org \
    --cc=js@linuxtv.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@rtr.ca \
    --cc=p.lundkvist@telia.com \
    --cc=pavel@ucw.cz \
    --cc=rjw@sisk.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox