From: Andrew Morton <akpm@zip.com.au>
To: Marek Michalkiewicz <marekm@amelek.gda.pl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: "laptop mode" for floppies too?
Date: Mon, 17 Jun 2002 03:02:15 -0700 [thread overview]
Message-ID: <3D0DB3A7.C32CCAE9@zip.com.au> (raw)
In-Reply-To: E17JssS-0006aL-00@alf.amelek.gda.pl
Marek Michalkiewicz wrote:
>
> Hi,
>
> I've just read (in Kernel Traffic - don't have enough time to follow
> linux-kernel directly...) about your proposed "laptop mode" patch
> (basically writing all dirty blocks to disk after it spins up - looks
> like a good idea to me). Similar problem exists with floppies (also
> in desktop PCs) - it takes a while to spin up, so I think it would
> make sense to write all dirty blocks just before spinning down, so
> that the drive is less likely to spin up again soon.
I kinda lost interest in `laptop mode'. The proposed simple, specific
implementation seemed to be deemed insufficient by many people, and
I believe that a fully-blown per-queue implementation would add an
unjustifiable amount of complexity. So I guess I'll submit the patch
which allows ext3 commit intervals to be tuned and leave it at that.
The key idea of writing back all dirty data when the disk is spun up
for a read can be implemented by a userspace daemon which polls /proc/stat
anyway.
> So it would be nice to have more general support for this feature in
> the block device layer (not limited to IDE devices). Is anyone working
> on something like that (for 2.5)?
Nobody is working on that.
You could get this effect by setting the `kupdate' interval short and
by setting the "maximum age of dirty data" small. So in 2.4 terms,
set the fifth parameter in /proc/sys/vm/bdflush to 100 (one second)
and set the sixth parameter to 200.
That will penalise the hard disk rather nastily, however.
A proper solution is not feasible with the 2.4 data structures.
In 2.5, making the "maximum age of dirty data" be a per-queue
tunable is in fact pretty simple. The trickiest part would be
exposing the per-queue tunables to userspace, actually.
I do need to revisit this stuff - we need a way of being able
to incorporate the nominal write bandwidth of the backing device
into the memory balancing decisions. I'll take a look at your
idea when I get onto that.
-
next prev parent reply other threads:[~2002-06-17 9:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-17 9:32 "laptop mode" for floppies too? Marek Michalkiewicz
2002-06-17 10:02 ` Andrew Morton [this message]
2002-06-17 12:34 ` Marek Michalkiewicz
2002-06-20 22:01 ` Daniel Kobras
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=3D0DB3A7.C32CCAE9@zip.com.au \
--to=akpm@zip.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=marekm@amelek.gda.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