|| ||Ingo Molnar <mingo-AT-elte.hu> |
|| ||Matthew Garrett <mjg59-AT-srcf.ucam.org> |
|| ||Re: Run-time PM idea (was: Re: [linux-pm] [RFC][PATCH 0/2] PM:
Rearrange core suspend code) |
|| ||Mon, 8 Jun 2009 15:46:47 +0200|
|| ||"Rafael J. Wysocki" <rjw-AT-sisk.pl>,
Alan Stern <stern-AT-rowland.harvard.edu>,
pm list <linux-pm-AT-lists.linux-foundation.org>,
ACPI Devel Maling List <linux-acpi-AT-vger.kernel.org>,
Magnus Damm <magnus.damm-AT-gmail.com>|
* Matthew Garrett <firstname.lastname@example.org> wrote:
> On Mon, Jun 08, 2009 at 03:22:35PM +0200, Ingo Molnar wrote:
> > * Matthew Garrett <email@example.com> wrote:
> > > The difficulty is in determining when it's viable to autosuspend a
> > > given device. There's a limit to how much we can determine purely
> > > from kernel state (for instance, we could suspend ahci when
> > > there's no pending disk access, but we'd lose hotplug
> > > notifications) so there's going to have to be some level of
> > > userspace policy determination. Having the infrastructure in the
> > > kernel is an important part of this, but there'll be some distance
> > > to go after that.
> > What will the 'user space policy' bit do what the kernel cannot?
> How does the kernel know whether the user cares about SATA hotplug
> or not?
The typical user probably doesnt know what 'SATA' means, and
probably has very vague concepts about 'hotplug' as well.
The kernel default should be: 'yes, if the kernel feature is enabled
and if the hardware can support it' (it's not on a blacklist of some
sort, etc., etc.).
> > If you mean the user has to configure something manually - that
> > wont really happen in practice. We are happy if they know where
> > to put those USB sticks in ;-)
> It'll be up to the distributions to provide sane defaults and let
> them be reconfigured as necessary, depending on the information we
> have from the user and maybe platform-specific knowledge. But this
> is a difficult problem - we need to be smart about all the
> potential sources of information in order to pick an appropriate
> policy, and the kernel's not the right layer to do some of this
> information collection.
What sources of information exactly? Again, the user wont enter
anything, in 95% of the cases - in the remaining 3% of cases what is
entered is wrong and only in another 2% of cases is it correct ;-)
Sane kernel defaults are important and the kernel sure knows what
kind of hardware it runs on. This 'let the user decide policy' for
something as fundamental (and also as arcane) as power saving mode
is really a disease that has caused a lot of unnecessary pain in
Linux in the past 15 years.
Sure, there might be tradeoffs when a piece of hardware cannot be
turned off sanely: obviously the monitor might not know it
(currently) whether someone is watching it, and
wake-on-packet-for-me is not commonly implemented in wireless and
wired networking cards so turning off an active networking card
might not be possible without the user asking allowing that
imperfect mode of power saving.
But there are plenty of cases where turning off hardware is fine,
and the broken special cases will go away as technology advances,
and we should not design based on broken concepts.
( Providing a way to _override_ those defaults is of course natural,
via /sysfs, should the user express an interest in tweaking it, or
should the kernel get it so wrong that a distro wants to work it
around. But your argument seems to be "push configuration and
handling into user-space" which is really backwards. )
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)