Matthew Garrett wrote:
I'd like F11 to be more useful for disk power management. This involves tuning various parameters in order to reduce disk access. There are some tradeoffs involved, so I'd like feedback before pushing much of this.
Great idea, i'm working quite a bit in that direction at them moment as well.
The first is relatime. I've just pushed Ingo's smarter relatime code towards upstream again. In this configuration atime will only be updated if the current atime is either older than ctime or mtime, or if the current atime is more than a day in the past. The amount of time required before atime is updated will be a tunable, and a norelatime mount parameter will be available to mount filesystems without this behaviour. This shouldn't affect the behaviour of any applications.
+1000. I've done a few tests here with my systems, and although the really bad offenders related to disk io are of course processes that do write access there are quite a few cases where read access happens which then has to update the atime and result in a write to the disc. :/
The second is to increase the value of dirty_writeback_centisecs. This will result in dirty data spending more time in memory before being pushed out to disk. This is probably more controversial. The effect of this is that a power interruption will potentially result in more data being lost. It doesn't alter the behaviour of fsync(), so paranoid applications will still get to ensure that their data is on disk. Of course, it would also be helpful to stop applications generating dirty pages where possible. This would obviously be reverted if the system enters a critical power state.
Sounds like a good idea. It's also something i've been looking at a bit. Take e.g. something like xchat. If you enable logging there you basically keep your disc active all the time as xchat itself doesn't use a large internal cache to write the data out every X MB or so.
Thirdly, I'd like to enable laptop mode by default. The effect of this is that any access that goes to disk will trigger an opportunistic flushing of dirty data shortly afterwards. To an extent this mitigates the change to dirty_writeback_centisecs, but there's obviously still some increased chance of data loss.
Agree as well, though i'm not sure if we should make it enabled by default as the risk of data loss in case of a system failure is quite high then.
The combination of these features should result in (on average) fewer disk accesses and so (on average) should provide better performance. There's a chance that some usage patterns will fall foul of this and lose performance, so if we do this I'd like to do it sufficiently early in the cycle that we can get real-world feedback.
Sounds like a great idea and something i've been working on myself lately, too. I even went a bit further and thought about the idea if a combination of a monitoring backend and a tuning engine could provide an automatic adoption of the system to the current use. E.g. during daytime when a user works with his machine we would typically see quite a few reads and write all the time. Drive spindowns or other power saving features could during that time be reduced so that the user will have the best performance. During the night (in case he didn't turn of the machine) only very few read and even fewer write operations should happen, at which time the disk could then be powered down most of the time. And of course this can be extended to not only disk drivces but other tunable hardware components.
Reagards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Team Lead Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch <pknirsch@xxxxxxxxxx> Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
