FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 11-27-2008, 03:38 PM
Matthew Garrett
 
Default RFC: Changing default filesystem parameters for power management reasons

On Thu, Nov 27, 2008 at 04:16:03PM +0000, Pádraig Brady wrote:

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

It can do, but I'd need to check if it does. You're right that the
tradeoffs are different there, so I'd want to spend a while looking at
that.

--
Matthew Garrett | mjg59@srcf.ucam.org

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-27-2008, 03:44 PM
Matthew Garrett
 
Default RFC: Changing default filesystem parameters for power management reasons

On Thu, Nov 27, 2008 at 09:59:08AM -0600, Eric Sandeen wrote:

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

Power-wise, I have measuring equipment here. Performance is obviously
harder - I suspect synthetic benchmarks will get much the same
performance as usual, so that might be down to waiting to see if users
complain.

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. I had a handwavy patch to do that, but we
probably want a good way of exposing that information to userspace.

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

Yes, the long-term plan involves allowing drive spindown. I'm hoping to
do this adaptively to let us avoid the spinup/down tendancies a static
timeout provides, but you're right that monitoring SMART information
would be a pretty important part of that. I lean towards offering it on
desktops and servers, but not enabled by default.

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

Mm. My recollection is that ext3 and xfs had easy to access tuning to
help in this respect. Changing the kernel defaults would be one option
there, or alternatively we could update fstab?

--
Matthew Garrett | mjg59@srcf.ucam.org

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-27-2008, 06:16 PM
Eric Sandeen
 
Default RFC: Changing default filesystem parameters for power management reasons

Matthew Garrett wrote:
> On Thu, Nov 27, 2008 at 09:59:08AM -0600, Eric Sandeen wrote:
>
>> 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).
>
> Power-wise, I have measuring equipment here. Performance is obviously
> harder - I suspect synthetic benchmarks will get much the same
> performance as usual, so that might be down to waiting to see if users
> complain.
>
> 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. I had a handwavy patch to do that, but we
> probably want a good way of exposing that information to userspace.

Yeah. Although you can tune things so that the block_dump stuff doesn't
go to /var/log/messages, but I'd played tricks in the past with saving
to ramdisks etc for this reason.

It'd also be nice if we could reliably query drives for their state, but
in the past the query itself has spun up some of my drives.

>> 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.
>
> Yes, the long-term plan involves allowing drive spindown. I'm hoping to
> do this adaptively to let us avoid the spinup/down tendancies a static
> timeout provides, but you're right that monitoring SMART information
> would be a pretty important part of that. I lean towards offering it on
> desktops and servers, but not enabled by default.

Sounds good. We don't want a "Fedora kills hard drives!" thread.

>> 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?
>
> Mm. My recollection is that ext3 and xfs had easy to access tuning to
> help in this respect. Changing the kernel defaults would be one option
> there, or alternatively we could update fstab?

Yep, they do. xfs even has a bit of code specifically to work w/ laptop
mode. Looks like the current laptop tools do handle ext3 & xfs from a
cursory glance. Should probably make sure that ext4 is properly handled
too.

-Eric

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-27-2008, 07:36 PM
Linus Walleij
 
Default RFC: Changing default filesystem parameters for power management reasons

tor 2008-11-27 klockan 15:33 +0000 skrev Matthew Garrett:

> I'd like F11 to be more useful for disk power management.

Cool!

> The first is relatime. I've just pushed Ingo's smarter relatime code
> towards upstream again.

Go for it!

> Thirdly, I'd like to enable laptop mode by default.

Are we talking of writing "5" into /proc/sys/vm/laptop_mode like for
desktops, servers, and laptops on mains power?

IIRC gnome-power-manager automatically enables this when the system goes
to run from battery, so I recon the idea is to make the laptop mode a
generic power-conservative mode, then should that be reflected in the
mainline kernel somehow by renaming said interface to ecosystem_mode or
something.

Is this really good for datacenter machines like database servers and
such, if we make it default?

> Any thoughts?

Great initiative!

You're mainly planning for kernel-level features for the whole line of
use cases and not at the level of userland tools like
gnome-power-manager that we currently rely on quite extensively to
manage power for desktops and laptops?

Linus

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-28-2008, 12:18 PM
Matthew Garrett
 
Default RFC: Changing default filesystem parameters for power management reasons

On Fri, Nov 28, 2008 at 12:33:53PM +0000, 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?

I was thinking of the vm_dump interface - I'd never noticed blktrace,
which looks pretty much ideal. Now we just need a user-friendly
front-end.

--
Matthew Garrett | mjg59@srcf.ucam.org

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-28-2008, 12:20 PM
Matthew Garrett
 
Default RFC: Changing default filesystem parameters for power management reasons

On Thu, Nov 27, 2008 at 09:36:17PM +0100, Linus Walleij wrote:

> You're mainly planning for kernel-level features for the whole line of
> use cases and not at the level of userland tools like
> gnome-power-manager that we currently rely on quite extensively to
> manage power for desktops and laptops?

I'm looking at making sure that we have sane defaults from a power
management perspective. Once that's done we can make sure that userland
can reconfigure stuff sensibly in response to various events, but I'm
hoping that for the most part we can find a solution that works without
needing that.

--
Matthew Garrett | mjg59@srcf.ucam.org

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-28-2008, 12:21 PM
Matthew Garrett
 
Default RFC: Changing default filesystem parameters for power management reasons

On Fri, Nov 28, 2008 at 06:49:55AM +0100, Thorsten Leemhuis wrote:

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

blktrace produces the information, but I wouldn't currently call it
"friendly".

--
Matthew Garrett | mjg59@srcf.ucam.org

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-28-2008, 12:24 PM
Matthew Garrett
 
Default RFC: Changing default filesystem parameters for power management reasons

On Fri, Nov 28, 2008 at 01:16:36PM +0100, Phil Knirsch wrote:

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

Indeed. There's been a fair amount of research into this - see
http://www.soe.ucsc.edu/~tbisson/papers/bisson-fast04.pdf for instance.
Some laptop drives will behave this way if APM settings are set
appropriately, but a decent implementation of this in userspace would be
very nice.

--
Matthew Garrett | mjg59@srcf.ucam.org

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-28-2008, 05:19 PM
Simo Sorce
 
Default RFC: Changing default filesystem parameters for power management reasons

On Fri, 2008-11-28 at 14:55 +0100, Phil Knirsch wrote:
> Ralf Ertzinger wrote:
> > Hi.
> >
> > On Fri, 28 Nov 2008 13:16:36 +0100, Phil Knirsch wrote:
> >
> >> 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.
> >
> > And why should it, honestly? Bufffering data ist the OSes job 99% of
> > the time. As long as xchat does not use fsync() after each write we
> > should be good.
> >
>
> Maybe i wasn't clear enough. But take for example the difference between
> xchat and say, syslog. I'd be really unhappy if i'd loose 1 hour of
> syslog data in the event of a system crash, but i couldn't care less if
> i'd loose 1 hour of xchatlogs during that time. So it is in that case
> application specific in a way, and the kernel can't (and shouldn't)
> semantically know how important your data is that you write with it. And
> currently you can either do a write() and let the data be flushed to
> disk automatically by the kernel every dirty_writeback_centisecs or
> directly use a flush() after your write to make sure data is written
> immediately. So the only way an application can currently "delay" those
> writes is by using internal buffers that fill up and get written once
> they are full. And the difference between 1 write every minute due to
> dirty_writeback_centisecs and 1 write every hour because the buffer
> takes that long to get filled is quite large imo.

Oh, but the kernel knows, the write() semantics clearly state that if
you want to make sure data is on disk you call flush(). If you don't
call flush() the kernel can delay flushing to disk indefinitely. So the
kernel have a very well defined way to know what apps want.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 12-01-2008, 02:04 PM
Bill Nottingham
 
Default RFC: Changing default filesystem parameters for power management reasons

Matthew Garrett (mjg@redhat.com) said:
> 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.

Works for me.

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

I'd be curious how this affects various workloads if we're changing
the global defaults. Were you planning on flipping the kernel defaults,
or just setting a default in sysctl.conf? (It occurs to me that laptop_mode
is horribly named.)

Bill

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

Thread Tools




All times are GMT. The time now is 07:37 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org