Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Development (http://www.linux-archive.org/fedora-development/)
-   -   RFC: Changing default filesystem parameters for power management reasons (http://www.linux-archive.org/fedora-development/200914-rfc-changing-default-filesystem-parameters-power-management-reasons.html)

Eric Sandeen 11-27-2008 02:59 PM

RFC: Changing default filesystem parameters for power management reasons
 
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.
>
> 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.

I could be convinced of this, I think, although there were a few nagging
bugs w/ older Fedoras that seemed related to this change, and honestly
never got to the bottom of them. But by and large Fedora already ran
this way w/ few problems in the past.

> 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

s/paranoid/proper/ :)

> 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.

I'll need to ponder these changes a bit more (and take another look at
laptop mode, it's been a while).

> The combination of these features should result in (on average) fewer
> disk accesses and so (on average) should provide better performance.

What are your plans to measure the results of these changes from power &
performance perspectives? Also, tools to monitor what is causing disk
accesses might be good (see also Bug 454582 - Tracker bug for
over-eager apps that won't let disks spin down).

Do you also have any plans for changing default disk spin-down times, or
would that be left to bios settings? And if so, we should probably
monitor this for how it jives with the expected lifetime of a disk vs.
lifetime rating for spindown cycles.

The original laptop mode kit included specific knowledge about some
filesystem tuning parameters (commit times etc), is that part of your
plan? Which filesystems will be recognized?

Thanks,
-Eric

> 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?

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Pádraig Brady 11-27-2008 03:16 PM

RFC: Changing default filesystem parameters for power management reasons
 
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.
>
> The first is relatime.
> The second is to increase the value of dirty_writeback_centisecs.
> Thirdly, I'd like to enable laptop mode by default.

Does the kernel export whether dev is an SSD.
If so, it would allow us to do a different combination of the above.

Generally userspace should do lots of things
differently/more efficiently if it knows a dev is an SSD.

Pádraig.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Thorsten Leemhuis 11-28-2008 04:49 AM

RFC: Changing default filesystem parameters for power management reasons
 
On 27.11.2008 16:33, Matthew Garrett wrote:
[...] 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.

[...]
Any thoughts?


Is there a "disktop" we could use to fine those app that generating
dirty pages without need? E.g. something as easy to use as powertop,
just for disks? If not I'd tend to say it might make sense to create
one, as finding and reporting the culprits that spin up the disks might
help this whole effort a lot.


CU
knurd

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Matthias Clasen 11-28-2008 04:54 AM

RFC: Changing default filesystem parameters for power management reasons
 
On Fri, 2008-11-28 at 06:49 +0100, Thorsten Leemhuis wrote:
> On 27.11.2008 16:33, Matthew Garrett wrote:
> > [...] 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.
> > [...]
> > Any thoughts?
>
> Is there a "disktop" we could use to fine those app that generating
> dirty pages without need? E.g. something as easy to use as powertop,
> just for disks? If not I'd tend to say it might make sense to create
> one, as finding and reporting the culprits that spin up the disks might
> help this whole effort a lot.

There is something called iotop.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Thorsten Leemhuis 11-28-2008 05:01 AM

RFC: Changing default filesystem parameters for power management reasons
 
On 28.11.2008 06:54, Matthias Clasen wrote:

On Fri, 2008-11-28 at 06:49 +0100, Thorsten Leemhuis wrote:

On 27.11.2008 16:33, Matthew Garrett wrote:
[...] 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.

[...]
Any thoughts?
Is there a "disktop" we could use to fine those app that generating
dirty pages without need? E.g. something as easy to use as powertop,
just for disks? If not I'd tend to say it might make sense to create
one, as finding and reporting the culprits that spin up the disks might
help this whole effort a lot.

There is something called iotop.


I wouldn't call iotop as easy to use at powertop. And the latter afaics
was such a success mainly because it was so easy to use.


CU
knurd

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Ralf Ertzinger 11-28-2008 08:00 AM

RFC: Changing default filesystem parameters for power management reasons
 
Hi.

On Fri, 28 Nov 2008 07:01:37 +0100, Thorsten Leemhuis wrote:

> I wouldn't call iotop as easy to use at powertop. And the latter
> afaics was such a success mainly because it was so easy to use.

And because it had those nice 'press X to turn off Y' hints.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Phil Knirsch 11-28-2008 11:16 AM

RFC: Changing default filesystem parameters for power management reasons
 
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@redhat.com>
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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Phil Knirsch 11-28-2008 11:20 AM

RFC: Changing default filesystem parameters for power management reasons
 
Ralf Ertzinger wrote:

Hi.

On Fri, 28 Nov 2008 07:01:37 +0100, Thorsten Leemhuis wrote:


I wouldn't call iotop as easy to use at powertop. And the latter
afaics was such a success mainly because it was so easy to use.


And because it had those nice 'press X to turn off Y' hints.



I've been looking at the existing system tap scripts lately for that and
most of them weren't aimed at that from what i could tell. I'm probably
going to rework one of them to basically do what powertop does for disk
io as i'm less interested in kb/sec reads and writes but more in
read/write operations per minute per process.


Regards, Phil

--
Philipp Knirsch | Tel.: +49-711-96437-470
Team Lead Core Services | Fax.: +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch <pknirsch@redhat.com>
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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

David Woodhouse 11-28-2008 11:33 AM

RFC: Changing default filesystem parameters for power management reasons
 
On Thu, 2008-11-27 at 16:44 +0000, Matthew Garrett wrote:
> It would be nice to have the kernel export disk access via a socket or
> something rather than the currently available debug option, which is to
> dump to dmesg which then triggers log writes which triggers more
> messages and fail occurs.

Does blktrace trigger log writes?

--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Eric Sandeen 11-28-2008 12:19 PM

RFC: Changing default filesystem parameters for power management reasons
 
David Woodhouse wrote:
> On Thu, 2008-11-27 at 16:44 +0000, Matthew Garrett wrote:
>> It would be nice to have the kernel export disk access via a socket or
>> something rather than the currently available debug option, which is to
>> dump to dmesg which then triggers log writes which triggers more
>> messages and fail occurs.
>
> Does blktrace trigger log writes?

shouldn't... but then it doesn't tell you what file was written to,
either (just blocks) because it's working lower down the stack. It
gives you a process name though at least.

One of the things I've found fairly often is applications which re-write
the same litle log or config file over and over, with unchanged
contents. It'd be nice if any disktop-like thing could check for that.
But that would require knowledge of what files were being accessed.

-Eric

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


All times are GMT. The time now is 10:47 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.