From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756227AbbA2TXf (ORCPT ); Thu, 29 Jan 2015 14:23:35 -0500 Received: from casper.infradead.org ([85.118.1.10]:57117 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753065AbbA2TXd (ORCPT ); Thu, 29 Jan 2015 14:23:33 -0500 Date: Thu, 29 Jan 2015 20:23:31 +0100 From: Peter Zijlstra To: Xunlei Pang Cc: Steven Rostedt , lkml , Juri Lelli Subject: Re: [PATCH 5/5] sched/rt: Optimize find_lowest_rq() to select a cache hot cpu Message-ID: <20150129192330.GR2896@worktop.programming.kicks-ass.net> References: <1421642980-10045-1-git-send-email-pang.xunlei@linaro.org> <1421642980-10045-5-git-send-email-pang.xunlei@linaro.org> <20150127142136.GE21418@twins.programming.kicks-ass.net> <20150127095626.707e434d@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22.1 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 30, 2015 at 12:42:47AM +0800, Xunlei Pang wrote: > On 27 January 2015 at 22:56, Steven Rostedt wrote: > > On Tue, 27 Jan 2015 15:21:36 +0100 > > Peter Zijlstra wrote: > > > >> On Mon, Jan 19, 2015 at 04:49:40AM +0000, Xunlei Pang wrote: > >> > In find_lowest_rq(), if we can't find a wake_affine cpu from > >> > sched_domain, then we can actually determine a cache hot cpu > >> > instead of simply calling "cpumask_any(lowest_mask)" which > >> > always returns the first cpu in the mask. > >> > > >> > So, we can determine the cache hot cpu during the interation of > >> > sched_domain() in passing. > >> > >> Steve, I'm not getting this. Why are we using WAKE_AFFINE here? > >> > > > > It originated from Gregory Haskins topology patches. See > > 6e1254d2c41215da27025add8900ed187bca121d > > Hi Peter, Steve, > > I think the responsiveness is the most important feature for RT tasks, > so I think: > response latency > cache > SMT in significance. No, deterministic execution time is the utmost important feature. And for that SMT utterly blows. So much so in fact that rule #1 for -rt work is to disable SMT on your hardware. The same argument can be made for shared caches. If your !rt workload blows away the cache of the rt workload, you loose. > I was wondering if we can take the cpuidle state into account like > current find_idlest_cpu() for CFS? > cpupri_find() can be easily modified to indicate the CPUPRI_IDLE case, > then we can select > an optimal idle cpu to improve RT tasks' responsiveness. For other > cases(mostly non-idle cpu), > I think we can rely on the existent sched_domain iteraction to select > a cache-hot cpu without > caring too much about SMT. your patch calls something 'cache-hot' when crossing large numa domains, don't you think that's somewhat stretching the definition of hot?