All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Lord <lkml@rtr.ca>
To: Andrew Morton <akpm@osdl.org>
Cc: js@linuxtv.org, pavel@ucw.cz, p.lundkvist@telia.com,
	linux-kernel@vger.kernel.org, rjw@sisk.pl
Subject: Re: [PATCH] Page writeback broken after resume: wb_timer lost
Date: Wed, 21 Jun 2006 00:10:55 -0400	[thread overview]
Message-ID: <4498C6CF.3080206@rtr.ca> (raw)
In-Reply-To: <20060620205415.d808ace9.akpm@osdl.org>

Andrew Morton wrote:
> On Tue, 20 Jun 2006 23:38:57 -0400
> Mark Lord <lkml@rtr.ca> wrote:
> 
>>> 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.
> 
> Are you able to come up with a foolproof set of steps which would allow the
> laggy-dirtiness to be reproduced by yours truly?

Heh.. don't I wish!

The best is still as described originally:

http://lkml.org/lkml/2006/2/6/170

Basically, "cat" a ton of huge files together into a single new one,
and then watch /proc/meminfo to see what happens.  For me, the count
there still just hangs at some big number like 500MB until I type "sync",
at which point it (nearly) instantly now goes to zero.

Previous to this patch, the "sync" actually resulted in a ton of disk writes,
but now those happen on the tail end of the "cat" command, as they should.

My kernel .config is available from http://rtr.ca/dell_i9300/kernel/latest/

Cheers

  reply	other threads:[~2006-06-21  4:10 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
2006-06-21  3:38           ` Mark Lord
2006-06-21  3:54             ` Andrew Morton
2006-06-21  4:10               ` Mark Lord [this message]
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=4498C6CF.3080206@rtr.ca \
    --to=lkml@rtr.ca \
    --cc=akpm@osdl.org \
    --cc=js@linuxtv.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.