Re: [RFC][PATCH] sched: Avoid select_idle_sibling() forwake_affine(.sync=true)

[Peter Zijlstra]

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.

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