Re: Run-time PM idea (was: Re: [linux-pm] [RFC][PATCH 0/2] PM:Rearrange core suspend code)
From: Ingo Molnar
Date: Mon Jun 08 2009 - 10:25:19 EST
* Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote:
> On Mon, Jun 08, 2009 at 03:46:47PM +0200, Ingo Molnar wrote:
> > * Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote:
> > > 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.
> eSATA is pretty common now.
[ And 99% of the CPUs have an IDT still 99.9% of the users dont know
what it is :) ]
> > 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.).
> The problem with this kind of default is that you get people who
> are confused that their hardware doesn't work.
If the hardware 'doesnt work' that is a kernel bug. Hardware that
_cannot be suspended_ safely (physically) should not be
auto-suspended, of course.
> If the kernel doesn't have enough information to make a decision
> it should err on the side of functionality - we're talking about
> fairly low-level power savings, but potentially several years of
> aggregate confusion on the part of users.
the difference between a 10W and a 1W footprint is a long series of
'low-level power savings'.
If users are getting confused and if hardware gets broken then tha's
a plain bug and the wrong path is being walked.
> > 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 ;-)
> Users are generally ok at realising correlation between a setting
> change and something no longer working, so as long as you provide
> that they'll be happy. I agree that this sucks. What we actually
> want is some means of reliably identifying whether a port is
> hotplug or not, but eSATA makes this very difficult.
Is it impossible?
> > 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.
> These cases can all be handled with sufficiently intelligent
> userland, so I'm not worried about them.
> > ( 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. )
> My argument is "Hardware should work, and if the kernel default is
> for it to be broken then the default is wrong". We went through
> this for USB autosuspend. Userspace simply has more available
> information than the kernel, and it's not just a matter of static
> configuration (though that may be part of it). For instance,
> Oliver's example of screensavers and USB keyboards. If nothing's
> paying attention to volume keys (or if the keyboard doesn't have
> any) then you can enable remote wakeup and suspend the keyboard.
> If something /is/ paying attention to volume keys, you can't do
> that. That's the kind of case I'm discussing.
See my reply to Oliver. This is really advocating a broken model of
device usage. That volume key usage dependency is being hidden from
the kernel, and then you want to kludge it around by pushing suspend
functionality to user-space? That way lies madness. The proper way
is to close the device if it's not used by anything. Then the kernel
can auto-suspend it just like it could auto-suspend network
interfaces that are not in use, or like it could auto-suspend a
dislay port that has no monitor or other output device attached.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/