lkml.org 
[lkml]   [2007]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-pm] Re: Hibernation considerations
    On Fri, 20 Jul 2007, Alan Stern wrote:

    > On Fri, 20 Jul 2007, Jeremy Maitin-Shepard wrote:
    >
    >>>> when doing a suspend-to-ram you get to a point where you just don't use
    >>>> any userspace.
    >>
    >>> What do you mean? How can you prevent user tasks from running? That's
    >>> basically what the freezer does, and the whole point of this approach
    >>> is to eliminate the freezer. Right?
    >>
    >> Presumably no tasks at all would be scheduled.
    >
    > How would you prevent tasks from being scheduled? How would you
    > prevent drivers from deadlocking because in order to put their device
    > in a low-power state they need to acquire a lock which is held by a
    > user task?

    you give up on the suspend becouse you have no way of getting the user
    task to give up the lock.

    however, kernel locks should not be held by user tasks, user tasks are not
    expected to behave in rational ways, allowing them to compete with kernel
    tasks for locks is a sure way to get a deadlock or indefinate stall.

    what locks are accessed this way?

    >>>> from that point on you are just walking the device tree
    >>>> putting things into low-power mode. This is the point where we are talking
    >>>> about jumping to.
    >>
    >>> Yes. And putting things into low-power mode requires the ability to
    >>> run the scheduler, which means that user tasks can be scheduled, which
    >>> means that they can run.
    >>
    >> Does it really (fundamentally) require scheduling tasks, particularly in
    >> the case that the devices have already been put in the "quiesced" state?
    >
    > I can't say for sure. That's the way we have been doing it. It
    > wouldn't be easy to change, because the driver would have to busy-wait
    > during delays -- which would mean it would need to use different code
    > for system-wide suspend and runtime suspend.

    please define terms so that we are all on the same page

    what do you mean by
    system-wide suspend
    runtime suspend

    David Lang
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-07-21 00:53    [W:4.396 / U:0.180 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site