From: Andrew Morton <akpm@osdl.org>
To: Peter Lundkvist <p.lundkvist@telia.com>
Cc: linux-kernel@vger.kernel.org, Pavel Machek <pavel@ucw.cz>,
"Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: [PATCH] Page writeback broken after resume: wb_timer lost
Date: Sat, 20 May 2006 10:37:28 -0700 [thread overview]
Message-ID: <20060520103728.6f3b3798.akpm@osdl.org> (raw)
In-Reply-To: <20060520130326.GA6092@localhost>
Peter Lundkvist <p.lundkvist@telia.com> wrote:
>
> Hi,
> I have noticed for some time that nr_dirty never drops but
> increases except when VM pressure forces it down. This only
> occurs after a resume, never on a freshly booted system.
>
> It seems the wb_timer is lost when the timer function is
> trying to start a frozen pdflush thread, and this occurs
> during suspend or resume.
>
> I have included a patch which work for me. Don't know if the
> test also should include a check for freezing to be safe, ie
> if ( !frozen(..) && !freezing(..) )
>
>
>
> diff -ru linux-2.6.17.org/mm/pdflush.c linux-2.6.17/mm/pdflush.c
> --- linux-2.6.17.org/mm/pdflush.c 2006-03-20 06:53:29.000000000 +0100
> +++ linux-2.6.17/mm/pdflush.c 2006-05-20 14:22:35.000000000 +0200
> @@ -213,12 +213,16 @@
> struct pdflush_work *pdf;
>
> pdf = list_entry(pdflush_list.next, struct pdflush_work, list);
> - list_del_init(&pdf->list);
> - if (list_empty(&pdflush_list))
> - last_empty_jifs = jiffies;
> - pdf->fn = fn;
> - pdf->arg0 = arg0;
> - wake_up_process(pdf->who);
> + if (!frozen(pdf->who)) {
> + list_del_init(&pdf->list);
> + if (list_empty(&pdflush_list))
> + last_empty_jifs = jiffies;
> + pdf->fn = fn;
> + pdf->arg0 = arg0;
> + wake_up_process(pdf->who);
> + }
> + else
> + ret = -1;
> spin_unlock_irqrestore(&pdflush_lock, flags);
> }
> return ret;
Maybe the code over in page-writeback.c should just rearm the timee within
the timer handler rather than waiting for a pdflush thread to do it. I'll
think about that.
But the main questions is: what on earth is going on here? We've taken a
kernel thread and we've done a wake_up_process() on it, but because it was
in a frozen state it just never gets to run, even after the resume.
Presumably it goes back into interruptible sleep after the resume. We took
it off the list (in the expectation that it'd run again) so we've lost
control of it.
Pavel, Rafael: this amounts to a lost wakeup. What's the story?
next prev parent reply other threads:[~2006-05-20 17:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-20 13:03 Peter Lundkvist
2006-05-20 17:37 ` Andrew Morton [this message]
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
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=20060520103728.6f3b3798.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--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
all inboxes | Powered by JetHome®