From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753405Ab3CACSN (ORCPT ); Thu, 28 Feb 2013 21:18:13 -0500 Received: from e23smtp06.au.ibm.com ([202.81.31.148]:45184 "EHLO e23smtp06.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751052Ab3CACSM (ORCPT ); Thu, 28 Feb 2013 21:18:12 -0500 Message-ID: <51300FD8.4070609@linux.vnet.ibm.com> Date: Fri, 01 Mar 2013 10:18:00 +0800 From: Michael Wang User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Mike Galbraith CC: LKML , Ingo Molnar , Peter Zijlstra , Paul Turner , Alex Shi , Andrew Morton , Ram Pai , "Nikunj A. Dadhania" , Namhyung Kim Subject: Re: [RFC PATCH] sched: wakeup buddy References: <512EFB4B.5040204@linux.vnet.ibm.com> <1362035917.4460.105.camel@marge.simpson.net> <512F09D4.1020307@linux.vnet.ibm.com> <1362038652.4460.124.camel@marge.simpson.net> <512F11E6.8060807@linux.vnet.ibm.com> <1362039862.4460.132.camel@marge.simpson.net> <512F1A15.2000609@linux.vnet.ibm.com> <1362043112.4460.163.camel@marge.simpson.net> In-Reply-To: <1362043112.4460.163.camel@marge.simpson.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13030102-7014-0000-0000-000002A7A5F1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/28/2013 05:18 PM, Mike Galbraith wrote: > On Thu, 2013-02-28 at 16:49 +0800, Michael Wang wrote: >> On 02/28/2013 04:24 PM, Mike Galbraith wrote: >>> On Thu, 2013-02-28 at 16:14 +0800, Michael Wang wrote: >>>> On 02/28/2013 04:04 PM, Mike Galbraith wrote: >>> >>>>> It would be nice if it _were_ a promise, but it is not, it's a hint. >>>> >>>> Bad to know :( >>>> >>>> Should we fix it or this is by designed? The comments after WF_SYNC >>>> cheated me... >>> >>> You can't fix it, because it's not busted. You can say "Ok guys, I'm >>> off for a nap RSN" all you want, but that won't guarantee that nobody >>> pokes you, and hands you something more useful to do than snoozing. >> >> So sync still means current is going to sleep, what you concerned is >> this promise will be easily broken by other waker, correct? > > That makes it a lie, and it can already have been one with no help. > Just because you wake one sync does not mean you're not going to find > another to wake. Smart tasks are taught to look before they leap. > >> Hmm.. may be you are right, if 'perf bench sched pipe' is not the one we >> should care, I have no reason to add this logical currently. > > Well, there is reason to identify task relationships methinks, you just > can't rely on the fact that you're alone on the rq at the moment, and > doing a sync wakeup to bind tasks. They _will_ lie to you :) I see. > >> I will remove this plus branch, unless I found other benchmark could >> benefit a lot from it. >> >> Besides this, how do you think about this idea? > > I like the idea of filtering true buddy pairs, and automagically > detecting the point when 1:N wants spreading rather a lot (fwtw). I'll > look closer at your method, but when it comes to implementation > opinions, the only one I trust comes out of a box in front of me. And please let me know how it works on your box ;-) Regards, Michael Wang > > I'm somewhat.. "taste challenged", Peter and Ingo have some though :) > > -Mike > > -- > 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/ >