lkml.org 
[lkml]   [2013]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH] sched: Avoid select_idle_sibling() for wake_affine(.sync=true)
    On Thu, Sep 26, 2013 at 04:35:33PM +0200, Peter Zijlstra wrote:
    > On Thu, Sep 26, 2013 at 04:39:30AM -0700, Paul Turner wrote:
    > > It is my intuition that there are a few common objects with fairly
    > > polarized behavior: I.e. For condition variables and producer
    > > consumer queues, a wakeup strongly predicts blocking. Whereas for
    > > locks protecting objects, e.g. a Mutex, would be expected to have the
    > > opposite behavior.
    >
    > Agreed; however none of those seem to have the property we're looking
    > for.
    >
    > Even produces consumer queues on their own don't generate the
    > alternating patterns we're looking for with the SYNC hint.
    >
    > We need a 'guarantee' that the waker is going to stop until the wakee is
    > done.
    >
    > What we're looking for is the typical synchronous request-reply like
    > pattern -- and that doesn't seem to correlate to any one locking object.
    >
    > Rather it is an inter-task relation; so task state does make sense in
    > finding them. We could for instance try and infer which task is
    > servicing requests; and then we know that requesting tasks will sleep
    > until reply.
    >

    Oh never mind, I see what you meant, the edges in that graph are the
    locks.

    Can't use RIPs for futexes though; you'd likely end up in the one
    pthread_mutex_lock() implementation or such.


    \
     
     \ /
      Last update: 2013-09-26 18:41    [W:2.345 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site