Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751453Ab3IZOfo (ORCPT ); Thu, 26 Sep 2013 10:35:44 -0400 Received: from merlin.infradead.org ([205.233.59.134]:51437 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750800Ab3IZOfn (ORCPT ); Thu, 26 Sep 2013 10:35:43 -0400 Date: Thu, 26 Sep 2013 16:35:33 +0200 From: Peter Zijlstra To: Paul Turner Cc: Mike Galbraith , Ingo Molnar , Rik van Riel , LKML Subject: Re: [RFC][PATCH] sched: Avoid select_idle_sibling() for wake_affine(.sync=true) Message-ID: <20130926143533.GE3657@laptop.programming.kicks-ass.net> References: <20130925075341.GB3081@twins.programming.kicks-ass.net> <1380099377.8523.9.camel@marge.simpson.net> <20130926095812.GR3081@twins.programming.kicks-ass.net> <20130926111618.GU3081@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1242 Lines: 29 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/