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.
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)?
As a nice side effect, removing a floppy while mounted but not spinning
would be a little less dangerous (still a bad idea of course, but might
happen by accident...) - the filesystem is more likely to be in some
consistent state, not in the middle of a write operation...
Thanks,
Marek
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.
-
Hi,
> 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.
Quite a lot of work to parse the /proc output that had to be nicely
formatted by the kernel first... And, that would be a global sync()
not per-device - looks like a hack to me.
> 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.
The "maximum age of dirty data" should be short (shorter than spin down
timeout) if the disk is already spinning, but longer if not spinning
so it won't spin up too often, otherwise there is little power saving.
Perhaps let the driver itself tune that value, depending on the current
state of the drive (spinning or not), easier than exposing to userspace.
The floppy driver itself controls the motor, so could also somehow
tell the kernel to write back all dirty data just before spinning down.
IDE disks can spin down automatically after some idle time, but perhaps
it would be more efficient if Linux could do that in software instead -
tell the disk to go to sleep ("hdparm -y") if it has not been accessed
for too long, but write all dirty data first (without resetting the idle
timer - possible now that the timer is ours and not in the disk).
OK, it's really a larger issue of more intelligent power management
than the hardware itself can do without OS support...
> 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.
Thanks. Yes, these days bandwidth can vary a lot between ATA100 disks
and floppies :)
Marek
On Mon, Jun 17, 2002 at 02:34:12PM +0200, Marek Michalkiewicz wrote:
> And, that would be a global sync() not per-device - looks like a hack
> to me.
You can also fsync() block devices to write out the buffers attached to
it. Slightly less of a hack that way.
> The floppy driver itself controls the motor, so could also somehow
> tell the kernel to write back all dirty data just before spinning down.
> IDE disks can spin down automatically after some idle time, but perhaps
> it would be more efficient if Linux could do that in software instead -
> tell the disk to go to sleep ("hdparm -y") if it has not been accessed
> for too long, but write all dirty data first (without resetting the idle
> timer - possible now that the timer is ours and not in the disk).
Have a look at noflushd (available via sourceforge). Never used it with
floppy disks, I admit, but the changes should be straightforward.
Regards,
Daniel.