RFC: Changing default filesystem parameters for power management reasons

Matthew Garrett mjg at redhat.com
Thu Nov 27 15:33:27 UTC 2008

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.

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.

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.

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.

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.

Any thoughts?
Matthew Garrett | mjg59 at srcf.ucam.org

More information about the fedora-devel-list mailing list