[lkml]   [2009]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Run-time PM idea (was: Re: [linux-pm] [RFC][PATCH 0/2] PM: Rearrange core suspend code)

    * Matthew Garrett <> wrote:

    > On Mon, Jun 08, 2009 at 03:46:47PM +0200, Ingo Molnar wrote:
    > >
    > > * Matthew Garrett <> 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.


     \ /
      Last update: 2009-06-08 16:27    [W:0.027 / U:3.308 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site