Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760229Ab3CHCvI (ORCPT ); Thu, 7 Mar 2013 21:51:08 -0500 Received: from e28smtp07.in.ibm.com ([122.248.162.7]:38158 "EHLO e28smtp07.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753474Ab3CHCvG (ORCPT ); Thu, 7 Mar 2013 21:51:06 -0500 Message-ID: <5139520C.1060109@linux.vnet.ibm.com> Date: Fri, 08 Mar 2013 10:50:52 +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: Peter Zijlstra CC: LKML , Ingo Molnar , Mike Galbraith , Namhyung Kim , Alex Shi , Paul Turner , Andrew Morton , "Nikunj A. Dadhania" , Ram Pai Subject: Re: [PATCH] sched: wakeup buddy References: <5136EB06.2050905@linux.vnet.ibm.com> <1362677252.10972.26.camel@laptop> In-Reply-To: <1362677252.10972.26.camel@laptop> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13030802-8878-0000-0000-0000062E4E4F Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1653 Lines: 49 On 03/08/2013 01:27 AM, Peter Zijlstra wrote: > On Wed, 2013-03-06 at 15:06 +0800, Michael Wang wrote: >> @@ -3351,7 +3420,13 @@ select_task_rq_fair(struct task_struct *p, int >> sd_flag, int wake_flags) >> } >> >> if (affine_sd) { >> - if (cpu != prev_cpu && wake_affine(affine_sd, p, >> sync)) >> + /* >> + * If current and p are wakeup related, and balance is >> + * guaranteed, we will try to make them running >> closely >> + * to gain cache benefit. >> + */ >> + if (cpu != prev_cpu && wakeup_related(p) && >> + wake_affine(affine_sd, p, >> sync)) >> prev_cpu = cpu; > > > OK, so there's two issues I have with all this are: > > - it completely wrecks task placement for things like interrupts (sadly > I don't > have a good idea about a benchmark where this matters). I don't get this point...could you please give more details? > - yet another random number.. :/ Correct...well, but that also means flexibility, I suppose different system and workload will need some tuning on this knob to gain more benefit, by default, they will gain some benefit, small or big. > > Also, I'm starting to dislike the buddy name; its somewhat over-used. > I have to agree :), any suggestions? Regards, Michael Wang -- 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/