lkml.org 
[lkml]   [2010]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Attempted summary of suspend-blockers LKML thread
    From
    2010/8/9 Rafael J. Wysocki <rjw@sisk.pl>:
    > On Monday, August 09, 2010, Arve Hjønnevåg wrote:
    >> 2010/8/8 Rafael J. Wysocki <rjw@sisk.pl>:
    >> > On Saturday, August 07, 2010, Arve Hjønnevåg wrote:
    >> >> 2010/8/7 Arve Hjønnevåg <arve@android.com>:
    >> >> > 2010/8/7 Rafael J. Wysocki <rjw@sisk.pl>:
    >> >> >> On Saturday, August 07, 2010, Arve Hjønnevåg wrote:
    >> >> >>> 2010/8/6 Alan Stern <stern@rowland.harvard.edu>:
    >> >> >>> > On Thu, 5 Aug 2010, Arve Hjønnevåg wrote:
    >> >> ...
    >> >> >>> >> total_time, total time the wake lock has been active. This one should
    >> >> >>> >> be obvious.
    >> >> >>> >
    >> >> >>> > Also easily added.
    >> >> >>> >
    >> >> >>> Only with a handle passed to all the calls.
    >> >> >>
    >> >> >> Well, I'm kind of tired of this "my solution is the only acceptable one"
    >> >> >> mindset.  IMHO, it's totally counter productive.
    >> >> >>
    >> >> >
    >> >> > How do you propose to track how long a driver has blocked suspend when
    >> >> > you have an unblock call that takes no arguments.
    >> >> >
    >> >>
    >> >> Also, I did not not see a response to my question about why you don't
    >> >> want to pass a handle.
    >> >
    >> > It doesn't really matter what I personally want.  In fact, I'm not totally
    >> > opposed to that idea, although there are disadvantages (eg. a "handle"
    >> > would really mean a pointer to an object with certain life cycle that needs to
    >> > be managed by the caller and it's not that clear to me who should manage the
    >> > objects that the PCI wakeup code would pass to pm_wakeup_event(), for one
    >>
    >> Wouldn't a single global handle work for the way you are handling pci
    >> wakeup events?
    >
    > Not really, because I'd like to know the number of wakeups associated with
    > the given device.
    >

    For debugging purposes right? I'm not sure automatically counting
    wakeup events from pm_stay_awake and pm_wakeup_event is the best way
    to do this. To avoid race conditions these calls have to be made for
    every event that could also be a wakeup event, which means the actual
    wakeup event easily gets lost in the noise. This is why I had a
    separate wakeup count that only increments on the fist call to
    wake_lock after each suspend, but this did not work that well either.

    >> It looked like you just reset a global timeout every time a pci wakeup event
    >> occurs.
    >
    > We bump up the per-device counter of wakeup events in addition to that.
    >
    >> > example).  I sent a pull request for your original patchset to Linus after all. :-)
    >> >
    >> > I said I didn't think "it would fly", meaning that I was afraid the other kernel
    >> > developers wouldn't like that change.
    >> >
    >> > The reason why I think so is that you'd like to add a whole new infrastructure
    >> > whose only purpose would be debugging that would only be useful to systems
    >> > using opportunistic suspend.  That, however, is only Android right now and it
    >> > cannot use the mainline kernel for other reasons, so basically we would add
    >> > infrastructure that's useful to no one.
    >> >
    >>
    >> I'm not sure what you mean by this. The debugging is useful for anyone
    >> using the api, not just Android, and a handle is also needed to mix
    >> timeouts and pm_relax.
    >
    > The purpose of the debugging would be to be able to figure out why the system
    > is staying in the working state, which is only relevant for systems that use
    > opportunistic suspend.
    >

    Only if the drivers do not have bugs. A driver calling pm_say_awake
    without a matching pm_relax call will prevent any race free suspend
    from succeeding.

    > If opportunistic suspend isn't used, it makes sense to ask which
    > device caused suspend (initiated by the user) to be aborted and for this
    > purpose it is sufficient to count wakeup events associated with each
    > device (you need to preserve the pre-suspend values of these counters, but
    > that can be done by a user space power manager just fine).
    >
    >> The handle can be the device, but some drivers need several handles per
    >> device.
    >
    > That depends on how precise the collected debug information should be and
    > that, in turn, depends on what it's going to be used for.
    >

    It is not just debug information. Drivers that mix wake_lock_timeout
    and wake_unlock do not map to the current api.

    > Anyway, as I said I'm not opposed to the idea of using a special type of
    > objects for collecting debug information on wakeup events, so please free to
    > submit patches modifying the current mainline kernel code in that direction.
    >

    How do you prefer to handle your pci wakeup events? Add a handle to
    every device or pci device? Or use a global handle to avoid the race
    and report wakeup events for debugging separately?

    --
    Arve Hjønnevåg
    --
    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: 2010-08-10 06:31    [W:0.030 / U:90.128 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site