"laptop mode"
Subsystems (5)
RFC 1/1 "laptop mode"
Here's a patch which is designed to make the kernel play more nicely with portable computers. I've been using it for a couple of days and it seems to do the right thing. I'm wondering if anyone has any comments/suggestions/etc.
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...
include/linux/sysctl.h renamed from include/linux/sysctl.h~pdflush-sysctl +12 -7
@@ -130,16 +130,21 @@ enum/* CTL_VM names: */ enum { -VM_SWAPCTL =1 ,/* struct: Set vm swapping control */ -VM_SWAPOUT =2 ,/* int: Linear or sqrt() swapout for hogs */ -VM_FREEPG =3 ,/* struct: Set free page thresholds */ +VM_UNUSED1 =1 ,/* was: struct: Set vm swapping control */ +VM_UNUSED2 =2 ,/* was; int: Linear or sqrt() swapout for hogs */ +VM_UNUSED3 =3 ,/* was: struct: Set free page thresholds */ VM_BDFLUSH_UNUSED =4 ,/* Spare */ VM_OVERCOMMIT_MEMORY =5 ,/* Turn off the virtual memory safety limit */ -VM_BUFFERMEM =6 ,/* struct: Set buffer memory thresholds */ -VM_PAGECACHE =7 ,/* struct: Set cache memory thresholds */ +VM_UNUSED4 =6 ,/* was: struct: Set buffer memory thresholds */ +VM_UNUSED5 =7 ,/* was: struct: Set cache memory thresholds */ VM_PAGERDAEMON =8 ,/* struct: Control kswapd behaviour */ -VM_PGT_CACHE =9 ,/* struct: Set page table cache parameters */ -VM_PAGE_CLUSTER =10 /* int: set number of pages to swap together */ +VM_UNUSED6 =9 ,/* was: struct: Set page table cache parameters */ +VM_PAGE_CLUSTER =10 ,/* int: set number of pages to swap together */ +VM_DIRTY_BACKGROUND =11 ,/* dirty_background_ratio */ +VM_DIRTY_ASYNC =12 ,/* dirty_async_ratio */ +VM_DIRTY_SYNC =13 ,/* dirty_sync_ratio */ +VM_DIRTY_WB_CS =14 ,/* dirty_writeback_centisecs */ +VM_DIRTY_EXPIRE_CS =15 ,/* dirty_expire_centisecs */ };
kernel/sysctl.c renamed from kernel/sysctl.c~pdflush-sysctl +14 -0
@@ -31,6 +31,7 @@#include <linux/init.h> #include <linux/sysrq.h> #include <linux/highuid.h> +#include <linux/writeback.h> #include <asm/uaccess.h>
@@ -264,6 +265,19 @@ static ctl_table vm_table[] = { &pager_daemon, sizeof(pager_daemon_t), 0644, NULL, &proc_dointvec}, {VM_PAGE_CLUSTER ,"page-cluster" , &page_cluster, sizeof(int), 0644, NULL, &proc_dointvec}, + {VM_DIRTY_BACKGROUND, "dirty_background_ratio", + &dirty_background_ratio,sizeof (dirty_background_ratio), + 0644, NULL, &proc_dointvec}, + {VM_DIRTY_ASYNC, "dirty_async_ratio", &dirty_async_ratio, + sizeof(dirty_async_ratio), 0644, NULL, &proc_dointvec}, + {VM_DIRTY_SYNC, "dirty_sync_ratio", &dirty_sync_ratio, + sizeof(dirty_sync_ratio), 0644, NULL, &proc_dointvec}, + {VM_DIRTY_WB_CS, "dirty_writeback_centisecs", + &dirty_writeback_centisecs,sizeof (dirty_writeback_centisecs),0644 , + NULL, &proc_dointvec}, + {VM_DIRTY_EXPIRE_CS, "dirty_expire_centisecs", + &dirty_expire_centisecs,sizeof (dirty_expire_centisecs),0644 , + NULL, &proc_dointvec}, {0} };
mm/page-writeback.c renamed from mm/page-writeback.c~pdflush-sysctl +42 -26
132 lines not on this page · raw message
include/linux/writeback.h renamed from include/linux/writeback.h~pdflush-sysctl +6 -0
@@ -45,6 +45,12 @@ static inline void wait_on_inode(struct/* * mm/page-writeback.c */ +extern int dirty_background_ratio; +extern int dirty_async_ratio; +extern int dirty_sync_ratio; +extern int dirty_writeback_centisecs; +extern int dirty_expire_centisecs; +void balance_dirty_pages (struct address_space *mapping);void balance_dirty_pages_ratelimited (struct address_space *mapping);int pdflush_operation (void (*fn)(unsigned long ),unsigned long arg0);
Documentation/filesystems/proc.txt renamed from Documentation/filesystems/proc.txt~pdflush-sysctl +32 -182
231 lines not on this page · raw message
Documentation/sysctl/vm.txt renamed from Documentation/sysctl/vm.txt~pdflush-sysctl +10 -133
164 lines not on this page · raw message
mm/page-writeback.c renamed from mm/page-writeback.c~laptop-mode +95 -6
149 lines not on this page · raw message
include/linux/sysctl.h renamed from include/linux/sysctl.h~laptop-mode +2 -0
@@ -145,6 +145,8 @@ enumVM_DIRTY_SYNC =13 ,/* dirty_sync_ratio */ VM_DIRTY_WB_CS =14 ,/* dirty_writeback_centisecs */ VM_DIRTY_EXPIRE_CS =15 ,/* dirty_expire_centisecs */ +VM_LAPTOP_MODE =16 ,/* Enter "laptop" writeback mode */ + VM_LAPTOP_WB_CS=17, /* Periodic flushtime when in laptop mode */ };
kernel/sysctl.c renamed from kernel/sysctl.c~laptop-mode +6 -0
@@ -20,6 +20,7 @@#include <linux/config.h> #include <linux/mm.h> +#include <linux/fs.h> #include <linux/slab.h> #include <linux/sysctl.h> #include <linux/swapctl.h>
@@ -278,6 +279,11 @@ static ctl_table vm_table[] = { {VM_DIRTY_EXPIRE_CS ,"dirty_expire_centisecs" , &dirty_expire_centisecs,sizeof (dirty_expire_centisecs),0644 , NULL, &proc_dointvec}, + {VM_LAPTOP_MODE, "laptop_mode", &laptop_mode, sizeof(laptop_mode), + 0644, NULL, &proc_dointvec}, + {VM_LAPTOP_WB_CS, "laptop_writeback_centisecs", + &laptop_writeback_centisecs,sizeof (laptop_writeback_centisecs), + 0644, NULL, &proc_dointvec}, {0} };
drivers/ide/ide.c renamed from drivers/ide/ide.c~laptop-mode +1 -0
@@ -1043,6 +1043,7 @@ static void do_request(struct ata_channevoid do_ide_request (request_queue_t *q) { +disk_spun_up ();do_request (q->queuedata); }
fs/jbd/transaction.c renamed from fs/jbd/transaction.c~laptop-mode +17 -5
@@ -45,7 +45,8 @@ extern spinlock_t journal_datalist_lock;static transaction_t *get_transaction (journal_t * journal,int is_try) { -transaction_t * transaction; +transaction_t *transaction; +unsigned long expires; transaction =jbd_kmalloc (sizeof (transaction_t),GFP_NOFS );if (!transaction)
@@ -56,14 +57,25 @@ static transaction_t * get_transaction ( transaction->t_journal = journal; transaction->t_state =T_RUNNING ; transaction->t_tid = journal->j_transaction_sequence++; - transaction->t_expires = jiffies + journal->j_commit_interval; -/* Set up the commit timer for the new transaction. */ -J_ASSERT (!journal->j_commit_timer_active); +/* +* Set up the commit timer for the new transaction. In laptop mode +* we expect commits to be forced by core kernel kupdate activity, so +* just set the transaction to expire five seconds after that in case +* something changes or goes wrong there. +*/ + expires = jiffies; +if (laptop_mode) + expires +=5 *HZ + (laptop_writeback_centisecs *HZ ) /100 ; +else + expires += journal->j_commit_interval; + + transaction->t_expires = expires; +J_ASSERT (!journal->j_commit_timer_active); journal->j_commit_timer_active =1 ; journal->j_commit_timer->expires = transaction->t_expires;add_timer (journal->j_commit_timer); - +J_ASSERT (journal->j_running_transaction ==NULL ); journal->j_running_transaction = transaction;
include/linux/fs.h renamed from include/linux/fs.h~laptop-mode +4 -0
@@ -1291,5 +1291,9 @@ static inline ino_t parent_ino(struct dereturn res; } +extern void disk_spun_up (void ); +extern int laptop_mode; +extern int laptop_writeback_centisecs; +#endif /* __KERNEL__ */ #endif /* _LINUX_FS_H */
Documentation/filesystems/proc.txt renamed from Documentation/filesystems/proc.txt~laptop-mode +32 -0
@@ -985,6 +985,38 @@ for writeout by the pdflush daemons. It Data which has been dirty in-memory for longer than this interval will be written out next time a pdflush daemon wakes up. +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. kswapd ------
Quoted 3 lines · Andrew Morton
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):
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.
-
Quoted 7 lines · Andrew Morton
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.
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/
Quoted 10 lines · Andreas Dilger
Quoted 7 lines · Andrew Morton
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.
Quoted 6 lines
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.
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.
-
Quoted 7 lines · Andrew Morton
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.
Quoted 11 lines · Xavier Bestel
Quoted 7 lines · Andrew Morton
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.
Quoted 2 lines
Have per-disk laptop-mode, so that some user-mode proggy (e.g. hotplug) could decide what to do.
But why?
-
Quoted 12 lines · Andrew Morton
Quoted 11 lines · Xavier Bestel
Quoted 7 lines · Andrew Morton
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.
Quoted 4 lines
Quoted 2 lines
Have per-disk laptop-mode, so that some user-mode proggy (e.g. hotplug) could decide what to do.
But why?
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 ?
I think a per-disk laptop mode is reasonable... one might have virtual ATA devices like this 128MB flash chip I have (you plug it right into an ATA socket, no cables needed. But I also agree that's a limited set of cases, and the additional complexity may not be worth it.
I've also thought in the past of having a "machine_policy" global variable, which could indicate to random userspace and kernel code a "laptop mode" or "file server mode" or "database server mode" etc.
Jeff
Quoted 1 line · Jeff Garzik
I've also thought in the past of having a "
machine_policy" global variable, which could indicate to random userspace and kernel code a "laptop mode" or "file server mode" or "database server mode" etc.
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.
I agree that this level of abstraction is the kernel's job. Deciding this sort of thing is best left for a user level tool (or the user with 'echo'). A generic set of tunables in /proc/sys/ makes sense, but deciding the best policy for a given set of parameters is a big problem and would be best solved outside of the kernel.
This is definitely the sort of thing that can be pushed to the user and should be.
} 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.
}
} -
} To unsubscribe from this list: send the line "unsubscribe linux-kernel" in } the body of a message to [email protected]
} More majordomo info at http://vger.kernel.org/majordomo-info.html
} Please read the FAQ at http://www.tux.org/lkml/
Hi!
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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
Quoted 8 lines · Andrew Morton
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).
Quoted 7 lines
- 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.
Am Mittwoch, 5. Juni 2002 01:31 schrieb Andreas Dilger:
Quoted 7 lines
[...]
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.
What parts of the filesystem needs to be accessed very often? I think, that placing var on a ramdisk, that is mirrored on the hd and is synced every 30 minutes, would be a good solution. I think, that we should add a sysrq key to save the ramdisk to the disk. Is there a similar project, that loads an image into a ramdisk at mount, and writes it back at unmount?
Quoted 3 lines
Yes, minutae, I know. Otherwise a nice idea.
Cheers, Andreas
Johnny
--snip/snip
Quoted 2 lines
What parts of the filesystem needs to be accessed very often? I think, that placing var on a ramdisk, that is mirrored on the hd and is synced every 30 minutes, would be a good solution. I think, that we should add a sysrq key to save the ramdisk to the disk. Is there a similar project, that loads an image into a ramdisk at mount, and writes it back at unmount?
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
Signature · 1 line
in some way i do, and in some way i don't.
Quoted 1 line · Thomas 'Dent' Mirlacher
--snip/snip
[snip/snip the Cc: list too..]
Quoted 10 lines
Quoted 2 lines
What parts of the filesystem needs to be accessed very often? I think, that placing var on a ramdisk, that is mirrored on the hd and is synced every 30 minutes, would be a good solution. I think, that we should add a sysrq key to save the ramdisk to the disk. Is there a similar project, that loads an image into a ramdisk at mount, and writes it back at unmount?
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?
Things like logfile appending...
(Do I need to say more ?)
I myself mount laptop filesystem with noatime option. Also killing cron/at helps somewhat.
Quoted 1 line
tm
/Matti Aarnio
Quoted 10 lines · Xavier Bestel
Quoted 7 lines · Andrew Morton
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.
Quoted 2 lines
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.
Signature · 1 line
Jens Axboe
Quoted 2 lines · Andrew Morton
laptop_mode
Great idea!.
drivers/ide/ide.c static void do_request(struct ata_channe · line 1048
Quoted 12 lines
This implementation doesn't try to be very smart - there's a direct ca
drivers/ide/ide.c renamed from drivers/ide/ide.c~laptop-mode +1
-0@@ -1043,6 +1043,7 @@ static void do_request(struct ata_channevoid 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?
Quoted 12 lines · Jens Axboe
Quoted 10 lines · Xavier Bestel
Quoted 7 lines · Andrew Morton
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.
Quoted 6 lines
Quoted 2 lines
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 therequest_fninstead 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?
-
Quoted 16 lines · Andrew Morton
Quoted 15 lines · Jens Axboe
Quoted 12 lines · Xavier Bestel
Quoted 7 lines · Andrew Morton
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.
Quoted 8 lines
Quoted 3 lines
And get rid of
disk_spun_up(), make it a queue flag instead and signal the spin up before calling therequest_fninstead 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.
Signature · 1 line
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Quoted 13 lines · Andrew Morton
Quoted 12 lines · Jens Axboe
Quoted 10 lines · Xavier Bestel
Quoted 7 lines · Andrew Morton
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.
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
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 therequest_fninstead of shoving it inside the driver request_fn's.Then writes to the ramdisk would cause a spinup.
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.
Quoted 2 lines
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.
Signature · 1 line
Jens Axboe
Quoted 6 lines · Hans-Christian Armingeon
What parts of the filesystem needs to be accessed very often? I think, that placing var on a ramdisk, that is mirrored on the hd and is synced every 30 minutes, would be a good solution. I think, that we should add a sysrq key to save the ramdisk to the disk. Is there a similar project, that loads an image into a ramdisk at mount, and writes it back at unmount?
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
Signature · 1 line
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth
Quoted 2 lines · Albert D. Cahalan
Also write out everything just before stopping the disk. Don't let the disk stop if there is any dirty data.
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
Quoted 3 lines · Andrew Pimlott
Quoted 2 lines
Also write out everything just before stopping the disk. Don't let the disk stop if there is any dirty data.
The kernel doesn't currently do spin-down at all, does it? Andrew,
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.
Signature · 3 lines
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/[email protected] 7179 3036 E136 B85D
Quoted 3 lines · Frank v Waveren
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.
Oops, it does say it doesn't work with any journaling elsewhere on the page. my bad.
Signature · 3 lines
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/[email protected] 7179 3036 E136 B85D
Quoted 12 lines · Andrew Pimlott
Quoted 2 lines · Albert D. Cahalan
Also write out everything just before stopping the disk. Don't let the disk stop if there is any dirty data.
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.
Quoted 1 line
I'm excited to try this. Thanks for writing it against 2.4!
At that point, you might as well be in userspace - particularly, you might as well be running/enhancing noflushd.
Signature · 2 lines
Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer
Quoted 8 lines · Jens Axboe
...
Quoted 2 lines
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:
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.
-
Hi!
Quoted 11 lines
Quoted 2 lines
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
Signature · 2 lines
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Hi!
Quoted 11 lines
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).
Quoted 7 lines
- 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!
Quoted 5 lines
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....
Quoted 5 lines
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 withinll_rw_blk.cbecause 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.
Pavel
Signature · 2 lines
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Hi!
Quoted 3 lines
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.
Quoted 3 lines
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
Hi!
Quoted 10 lines
Quoted 6 lines
Quoted 2 lines
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...
Pavel
Signature · 2 lines
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Hi!
Quoted 2 lines
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 2 lines
but you apply the same logic to just one (for instance) of your disks on a home desktop system.
Signature · 2 lines
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.