Messages in this thread | | | Date | Thu, 26 Sep 2013 17:43:03 +0200 | From | Peter Zijlstra <> | Subject | Re: [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.
| |