Just FYI, this is probably an optimally bad choice for the default disk
spinup interval, as many laptops spindown timers in the same ballpark.
I would say 15-20 minutes or more, unless there is a huge amount of
VM pressure or something. Otherwise, you will quickly have a dead
laptop harddrive from the overly-frequent spinup/down cycles.
Yes, minutae, I know. Otherwise a nice idea.
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
I just had a brainwave. The following text has been added...
Aside: there is another reason why disks spin up more often than
necessary: an application has only read a part of a file, and it needs
to fetch more of that file later on. This commonly happens with the
pagein of executables. To fix this you can increase the readahead
tunable of your disk drive to something enormous (say, one gigabyte):
blockdev --setra 2097152 /dev/hda
Once this is done, the readahead code will effectively read entire
files into memory when the application attempts to read just a small
part of that file. So later access to other parts of that file will
not require another spinup.
-
Twenty it is, thanks.
BTW, the "use a gigabyte of readahead" idea would cause VM hysteria
if you access a 600 megabyte file, so I've wound that back to
twenty megs.
Also, it has been suggested that the feature become more fully-fleshed,
to support desktops with one disk spun down, etc. It's not really
rocket science to do that - the `struct backing_dev_info' gives
a specific communication channel between the high-level VFS code and
the request queue. But that would require significantly more surgery
against the writeback code, so I'm fishing for requirements here. If
the current (simple) patch is sufficient then, well, it is sufficient.
To test this code you'll also need
http://www.zip.com.au/~akpm/linux/patches/2.4.20/pdflush-sysctl.patch
(hmm. Server seems to be dead. So the patches are here, as attachments)
Here's the algorithm, from the Documentation/filesystems/proc.txt
section describing /proc/sys/vm/:
laptop_mode
-----------
Setting this entry to '1' will put the kernel's dirty data writeout
algorithms into a mode which is better suited to laptop/notebook
computers. This mode is specifically designed to minimise the
frequency of disk spinups. Laptop mode works as follows:
- Dirty data remains in memory for longer periods of time (controlled
by laptop_writeback_centisecs).
- If there is pending dirty data and the disk is spun up for any
reason (even for a read) then all dirty data will be written back
shortly afterwards. ie: when the disk is spun up, make good use of
it.
- When the decision is made to write back some dirty data, the kernel
will write back all dirty data.
laptop_writeback_centisecs
--------------------------
This tunable determines the maximum age of dirty data when the machine
is operating in Laptop mode. The default value is 30000 - five
minutes. This means that if applications are generating a small amount
of write traffic, the disk will spin up once per five minutes.
If the disk is spun up for any other reason (such as for a read) then
all dirty data will be flushed anyway, and this timer is reset to zero.
laptop_writeback_centisecs has no effect when the machine is not
operating in Laptop mode.
This implementation doesn't try to be very smart - there's a direct
call out of do_ide_request() into the writeback code. This couldn't
be done from within ll_rw_blk.c because then a write to the ramdisk
would spin the disk up. Even as-is, a read from the IDE CDROM
drive will cause the IDE hard disk to spin up and flush data, so
probably that call in do_ide_request() should only be made if the
device is writable. Suggestions are sought, but let's try not to
get too fancy here...
> Setting this entry to '1' will put the kernel's dirty data writeout
> algorithms into a mode which is better suited to laptop/notebook
> computers. This mode is specifically designed to minimise the
> frequency of disk spinups. Laptop mode works as follows:
>
> - Dirty data remains in memory for longer periods of time (controlled
> by laptop_writeback_centisecs).
>
> - If there is pending dirty data and the disk is spun up for any
> reason (even for a read) then all dirty data will be written back
> shortly afterwards. ie: when the disk is spun up, make good use of
> it.
>
> - When the decision is made to write back some dirty data, the kernel
> will write back all dirty data.
Also write out everything just before stopping the disk.
Don't let the disk stop if there is any dirty data.
a nice thing for that would be to have unionfs (al viro seems to work on that?),
and mount a ramdisk ontop of your var directory (or shichever directory is
a hotspot. - or mount it over your whole harddrive, doing COW on the ramdisk.
and once the disk reaches a critical high-water-mark sync the whole set to
the underlaying "real" filesystem.
any comments?
tm
--
in some way i do, and in some way i don't.
But why?
-
> Also, it has been suggested that the feature become more fully-fleshed,
> to support desktops with one disk spun down, etc. It's not really
> rocket science to do that - the `struct backing_dev_info' gives
> a specific communication channel between the high-level VFS code and
> the request queue. But that would require significantly more surgery
> against the writeback code, so I'm fishing for requirements here. If
> the current (simple) patch is sufficient then, well, it is sufficient.
Have per-disk laptop-mode, so that some user-mode proggy (e.g. hotplug)
could decide what to do.
And get rid of disk_spun_up(), make it a queue flag instead and signal
the spin up before calling the request_fn instead of shoving it inside
the driver request_fn's.
--
Jens Axboe
>
> laptop_mode
Great idea!.
>
> This implementation doesn't try to be very smart - there's a direct
> ca
> --- 2.5.20/drivers/ide/ide.c~laptop-mode Tue Jun 4 15:27:54 2002
> +++ 2.5.20-akpm/drivers/ide/ide.c Tue Jun 4 15:27:54 2002
> @@ -1043,6 +1043,7 @@ static void do_request(struct ata_channe
>
> void do_ide_request(request_queue_t *q)
> {
> + disk_spun_up();
> do_request(q->queuedata);
> }
Hugh? Perhaps moving this down to do_request would be
an idea worth consideration?
No of course not, that is what the queue flag would say (is this a disk
or not, or something to that effect). Besides, ram disk doesn't even use
a request_fn.
> Yes, it could be per-queue. That would add complexity to
> the already-murky fs/fs-writeback.c. It that justifiable?
I dunno, it's up to you. I guess this is mainly IDE specific anyways,
but you apply the same logic to just one (for instance) of your disks on
a home desktop system.
--
Jens Axboe
e.g. not mess with cdroms, autoalimented disks, some mp3-players seen as
usb-storage, whatever.
I just realized your patch was partly ide-specific, perhaps what I said
doesn't apply ?
Things like logfile appending...
(Do I need to say more ?)
I myself mount laptop filesystem with noatime option.
Also killing cron/at helps somewhat.
> tm
/Matti Aarnio
Then writes to the ramdisk would cause a spinup.
Yes, it could be per-queue. That would add complexity to
the already-murky fs/fs-writeback.c. It that justifiable?
-
It's all there already. Just killall -STOP kupdated, use
sys_readahead() to read your often needed files into pagecache
and SysRq+S to sync, if needed.
Your solution involves copying things twice and using memory
twice, so it is not the right approach.
Andrews point was to control flushing by the power state of the
ide device.
Regards
Ingo Oeser
--
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth
The kernel doesn't currently do spin-down at all, does it? Andrew,
are you planning to change this? I'm not a kernel programmer, but
it seems like a good idea to me: The kernel could flush writes as
usual while the disk is spun up, but still spin down after a bit if
the rate is low enough. The disk would never spin itself down in
that case. Maybe there are also cases where the kernel would delay
spin-down, if it hasn't started writing but thinks it might soon.
I'm excited to try this. Thanks for writing it against 2.4!
Andrew
--
Frank v Waveren Fingerprint: 0EDB 8787
fvw@[var.cx|stack.nl|dse.nl|chello.nl] ICQ#10074100 09B9 6EF5 6425 B855
Public key: hkp://wwwkeys.pgp.net/f...@var.cx 7179 3036 E136 B85D
People interested in this should also have a look at noflushd
(http://noflushd.sourceforge.net/), which does something quite
similar. Only problem atm is it doesn't play nice with journalling
filesystems.. The bugs only list reiserfs, but I didn't have any luck with
it on ext3 either a while back.
--
At that point, you might as well be in userspace - particularly, you
might as well be running/enhancing noflushd.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
Well it's a convenience thing. Not really worth a lot of code.
I expect most of the proposed functionality could be provided
from userspace anyway via the disk IO number in /proc/stat:
old_counts=get_counters()
while 1 {
sleep 5
if (old_counts != get_counters()) {
sync
sleep 10
old_counts = get_counters()
}
}
This doesn't have the "if we flushed for any reason, reset the
timer" optimisation. But it will work in 2.4.
So I think I'll just settle for making the ext3 journal timer
expiries tunable.
-
I'm not too sure this level of abstraction is needed by userspace.
It would be enough if the appropriate things were all controlable
in /proc/sys/ etc. and then you just have:
/etc/sysctl.{laptop,server,desktop}.conf
It would be better to have it explicit in userspace as you're
always going to need to tweak things IMHO.
Padraig.
This is definitely the sort of thing that can be pushed to the user and
should be.
> > > Also, it has been suggested that the feature become more fully-fleshed,
> > > to support desktops with one disk spun down, etc. It's not really
> > > rocket science to do that - the
> BTW, the "use a gigabyte of readahead" idea would cause VM hysteria
> if you access a 600 megabyte file, so I've wound that back to
> twenty megs.
Twenty megs is still way too much I believe. Well, definitely way too much
on 32MB machine, and I do not think it is required at all.
> > Yes, it could be per-queue. That would add complexity to
> > the already-murky fs/fs-writeback.c. It that justifiable?
Doing it per-queue is right, doing is per-system is clearly wrong.
> I dunno, it's up to you. I guess this is mainly IDE specific anyways,
SCSI can do spindowns, too, and it *needs* kernel support for that. On
IDE, this can be (in a racy way) done userspace, too.
> but you apply the same logic to just one (for instance) of your disks on
> a home desktop system.
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
> > Here's a patch which is designed to make the kernel play more nicely
> > with portable computers.
>
> I just had a brainwave. The following text has been added...
>
>
> Aside: there is another reason why disks spin up more often than
> necessary: an application has only read a part of a file, and it needs
> to fetch more of that file later on. This commonly happens with the
> pagein of executables. To fix this you can increase the readahead
> tunable of your disk drive to something enormous (say, one gigabyte):
This was not required in my configs...
Pavel
> laptop_mode
> -----------
>
> Setting this entry to '1' will put the kernel's dirty data writeout
> algorithms into a mode which is better suited to laptop/notebook
> computers. This mode is specifically designed to minimise the
> frequency of disk spinups. Laptop mode works as follows:
>
> - Dirty data remains in memory for longer periods of time (controlled
> by laptop_writeback_centisecs).
>
> - If there is pending dirty data and the disk is spun up for any
> reason (even for a read) then all dirty data will be written back
> shortly afterwards. ie: when the disk is spun up, make good use of
> it.
>
> - When the decision is made to write back some dirty data, the kernel
> will write back all dirty data.
Nice!
> laptop_writeback_centisecs
> --------------------------
>
> This tunable determines the maximum age of dirty data when the machine
> is operating in Laptop mode. The default value is 30000 - five
Well, I run my notebooks in similar mode with writeback set essentialy to
infinity. I do it even on my home server....
> This implementation doesn't try to be very smart - there's a direct
> call out of do_ide_request() into the writeback code. This couldn't
> be done from within ll_rw_blk.c because then a write to the ramdisk
> would spin the disk up. Even as-is, a read from the IDE CDROM
> drive will cause the IDE hard disk to spin up and flush data, so
It would nice to do this per disk.... If you have server with one active
and one inactive disk, you want the inactive one to sleep.
> > > Yes, it could be per-queue. That would add complexity to
> > > the already-murky fs/fs-writeback.c. It that justifiable?
> >
> > I dunno, it's up to you. I guess this is mainly IDE specific anyways,
> > but you apply the same logic to just one (for instance) of your disks on
> > a home desktop system.
>
> Well it's a convenience thing. Not really worth a lot of code.
> I expect most of the proposed functionality could be provided
> from userspace anyway via the disk IO number in /proc/stat:
noflushd is about that...
> Jens Axboe wrote:
> >
> > On Wed, Jun 05 2002, Xavier Bestel wrote:
> > > Le mer 05/06/2002 à 01:43, Andrew Morton a écrit :
> > >
> > > > Also, it has been suggested that the feature become more fully-fleshed,
> > > > to support desktops with one disk spun down, etc. It's not really
> > > > rocket science to do that - the `struct backing_dev_info' gives
> > > > a specific communication channel between the high-level VFS code and
> > > > the request queue. But that would require significantly more surgery
> > > > against the writeback code, so I'm fishing for requirements here. If
> > > > the current (simple) patch is sufficient then, well, it is sufficient.
> > >
> > > Have per-disk laptop-mode, so that some user-mode proggy (e.g. hotplug)
> > > could decide what to do.
> >
> > And get rid of disk_spun_up(), make it a queue flag instead and signal
> > the spin up before calling the request_fn instead of shoving it inside
> > the driver request_fn's.
>
> Then writes to the ramdisk would cause a spinup.
>
> Yes, it could be per-queue. That would add complexity to
> the already-murky fs/fs-writeback.c. It that justifiable?
Yes, see Zip and USB/Firewire drives. Laptops can have multiple spindles.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."