From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753312AbdHPBmF (ORCPT ); Tue, 15 Aug 2017 21:42:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:48654 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753195AbdHPBmE (ORCPT ); Tue, 15 Aug 2017 21:42:04 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E373722B4C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Tue, 15 Aug 2017 21:42:01 -0400 From: Steven Rostedt To: Byungchul Park Cc: peterz@infradead.org, mingo@kernel.org, linux-kernel@vger.kernel.org, juri.lelli@gmail.com, kernel-team@lge.com Subject: Re: [PATCH v6 1/2] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq() Message-ID: <20170815214201.15b6424b@gandalf.local.home> In-Reply-To: <20170816003810.GO20323@X58A-UD3R> References: <1502077834-11137-1-git-send-email-byungchul.park@lge.com> <1502077834-11137-2-git-send-email-byungchul.park@lge.com> <20170815111940.07c7f3de@gandalf.local.home> <20170816003810.GO20323@X58A-UD3R> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 16 Aug 2017 09:38:11 +0900 Byungchul Park wrote: > On Tue, Aug 15, 2017 at 11:19:40AM -0400, Steven Rostedt wrote: > > > @@ -1385,6 +1407,17 @@ static int find_later_rq(struct task_struct *task) > > > * already under consideration through later_mask. > > > */ > > > if (best_cpu < nr_cpu_ids) { > > > + /* > > > + * If current domain is SD_PREFER_SIBLING > > > + * flaged, we have to get more chances to > > > + * check other siblings. BTW, "we have to get more chances" doesn't really make sense. Do you mean "we need to try other domains"? > > > + */ > > > + if (sd->flags & SD_PREFER_SIBLING) { > > > + prefer = sd; > > > > Is this how the SD_PREFER_SIBLING works? According to this, the > > preferred sd is the next sd in for_each_domain(). Not to mention, the > > prefer variable stays set if the next domain has no available CPUs. Is > > that what we want? > > Maybe I don't understand what you want to say. The variable, prefer, is > used to pick up the smallest sched domain among SD_PREFER_SIBLING > domains, if more than one SD_PREFER_SIBLING domain exist in the visit. > > The prefer variable alway points to the previous SD_PREFER_SIBLING domain. > And that must stay set to be used as a fallback choise if the next domain > has no available CPUs. > > Could you explain what I mis-understand? > I may be the one confused here ;-) I think I misread the patch. So, the SD_PREFER_SIBLING means to try to find a CPU in another sd instead? Thus, we try to find a CPU in a sd that does not have SD_PREFER_SIBLING set. And if there is none, we use the preferred sd as a fallback. Is that correct? I'm not familiar with the SD_PREFER_SIBLING flag, the only documentation I can find about it is the comment that states: /* Prefer to place tasks in a sibling domain */ And the very informative git commit change log: commit b5d978e0c7e79a7ff842e895c85a86b38c71f1cd Date: Tue Sep 1 10:34:33 2009 +0200 sched: Add SD_PREFER_SIBLING Do the placement thing using SD flags. ;-) -- Steve