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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
