lkml.org 
[lkml]   [2010]   [Jun]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v4] pm_qos: make update_request non blocking
    On Wed, 09 Jun 2010 13:05:49 -0400
    James Bottomley <James.Bottomley@suse.de> wrote:
    > On Wed, 2010-06-09 at 18:32 +0200, Florian Mickler wrote:
    > > On Wed, 09 Jun 2010 12:07:25 -0400
    > > James Bottomley <James.Bottomley@suse.de> wrote:
    > > > OK, so the expression of the race is that the latest notification gets
    > > > lost. If something is tracking values, you'd really like to lose the
    > > > previous one (which is now irrelevant) not the latest one. The point is
    > > > there's still a race.
    > > >
    > > > James
    > > >
    > >
    > > Yeah, but for blocking notification it is not that bad.
    >
    > The network latency notifier uses the value to recalculate something.
    > Losing the last value will mean it's using stale data.

    Actually after pondering a bit, it is not stale data that gets
    delivered: (Correct me if I'm wrong)

    The update_notify() function determines the extreme value and then
    calls the blocking_notifier_chain.

    But just before the update_notify() function get's called, the
    work-structure is reset and re-queue-able. So it is possible to queue it
    already even before the extreme_value in update_notify get's
    determined.

    So the notified value is always the latest or there is another
    notification underway.

    >
    > > Doesn't using blocking notifiers mean that you need to always check
    > > via pm_qos_request() to get the latest value anyways? I.e. the
    > > notification is just a hint, that something changed so you can act on
    > > it. But if you act (may it because of notification or because of
    > > something other) then you have to get the current value anyways.
    >
    > Well, the network notifier assumes the notifier value is the latest ...
    >
    > > I think there are 2 schemes of operation. The one which needs
    > > atomic notifiers and where it would be bad if we lost any notification
    > > and the other where it is just a way of doing some work in a timely
    > > fashion but it isn't critical that it is done right away.
    > >
    > > pm_qos was the second kind of operation up until now, because the
    > > notifiers may have got scheduled away while blocked.
    >
    > Actually, no ... the current API preserves ordering semantics. If a
    > notifier sleeps and another change comes along, the update callsite will
    > sleep on the notifier's mutex ... so ordering is always preserved.

    If my above thinkings are right, then the change in semantics is only,
    that now you can not determine by the number of notifications the
    number of update_request-calls.

    >
    > James
    >

    Cheers,
    Flo


    \
     
     \ /
      Last update: 2010-06-10 09:49    [W:4.405 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site