Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4245657pxj; Tue, 25 May 2021 03:44:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwbKXmCVPGj+Z6Si/QbvERr6yDWFprqGK9GrmF7Jt0R8H+mvBr2hzG3x0inKXRrwT+m4rPN X-Received: by 2002:a05:6402:188:: with SMTP id r8mr30642882edv.75.1621939458358; Tue, 25 May 2021 03:44:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621939458; cv=none; d=google.com; s=arc-20160816; b=vN+TXc3/XGLUr6mGqn06eFddDglOXYAIf5fV1YrDTUCc34XZDzdu5Fz4tbDlikFd89 ztuq1FLNZPqyqkJAM8tfy6bDbKsmiTwTrGtLMBU4zoR+Nrnapn5cmaE77SN0lbxyOInZ FINpJgyfwmNdGj1tui2FvBEGjDPNHLKqjDcIQKpMI4/uweIxys/D/F6uvgXOCE3uKsy7 IZsuc2diBcpmBzD45WTLjSVWz8yIuSN0yAJVyEwah4gIWtTD9INh1bnuhg+OJltvfJQc XHR+dBOeLvfaYLRsg1kJGIyG6fyFI8ZagGBzKmpgaNRyV56S9EJNrMOR6Dw4GTPEnnx8 3lUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=e47oFYmASiojjflt0MZaumVPkyLThFf96PceoFRl30M=; b=NVFJDvQkD13WUSz8C7cHUKOxYf3UMS/hNgKWx0WQNtD9GCWvdq27MYfjbzSl+kr4r0 mZPEdGH5V0gC7FgkE0jnLBZclZ13ZaZZSj/pt7W1JzFKUGvdd7695oWjbwwbvFofTykQ WSSDQXXd559XlRtiPQWTqhW1XHr22nOce3hCf6siCftOedeA0PXERVZ0wPAwwlQodS4W BzaAuFammtITCYKy4ym3cjikg4TU/ar+TLsTTfcMTKDrcdWUhdHvZmZjuKGshaviw5yC z/nXqo2r4XQRRrI4ipjLnU7E0WhuHBbaNMK7AfTGBw14FuV2GCG1kRrIdTBMFF8Bg68b DTVw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l19si14885461ejq.96.2021.05.25.03.43.55; Tue, 25 May 2021 03:44:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231470AbhEYKb3 (ORCPT + 99 others); Tue, 25 May 2021 06:31:29 -0400 Received: from foss.arm.com ([217.140.110.172]:54418 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231730AbhEYKbZ (ORCPT ); Tue, 25 May 2021 06:31:25 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CFDCDD6E; Tue, 25 May 2021 03:29:55 -0700 (PDT) Received: from e120325.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 556313F719; Tue, 25 May 2021 03:29:54 -0700 (PDT) Date: Tue, 25 May 2021 11:29:46 +0100 From: Beata Michalska To: Valentin Schneider Cc: linux-kernel@vger.kernel.org, peterz@infradead.org, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, corbet@lwn.net, rdunlap@infradead.org, linux-doc@vger.kernel.org Subject: Re: [PATCH v5 2/3] sched/topology: Rework CPU capacity asymmetry detection Message-ID: <20210525102945.GA24210@e120325.cambridge.arm.com> References: <20210524101617.8965-1-beata.michalska@arm.com> <20210524101617.8965-3-beata.michalska@arm.com> <87fsyc6mfz.mognet@arm.com> <20210524225508.GA14880@e120325.cambridge.arm.com> <87a6oj6sxo.mognet@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a6oj6sxo.mognet@arm.com> User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 25, 2021 at 10:53:07AM +0100, Valentin Schneider wrote: > On 24/05/21 23:55, Beata Michalska wrote: > > On Mon, May 24, 2021 at 07:01:04PM +0100, Valentin Schneider wrote: > >> On 24/05/21 11:16, Beata Michalska wrote: > >> > This patch also removes the additional -dflags- parameter used when > >> ^^^^^^^^^^^^^^^^^^^^^^^ > >> s/^/Also remove/ > > I would kind of ... disagree. > > All the commit msg is constructed using passive structure, the suggestion > > would actually break that. And it does 'sound' bit imperative but I guess > > that is subjective. I'd rather stay with impersonal structure (which is > > applied through out the whole patchset). > > It's mainly about the 'This patch' formulation, some take exception to that :-) > Will rephrase > >> > >> > building sched domains as the asymmetry flags are now being set > >> > directly in sd_init. > >> > > >> > >> Few nits below, but beyond that: > >> > >> Tested-by: Valentin Schneider > >> Reviewed-by: Valentin Schneider > >> > > Thanks a lot for the review and testing! > > > >> > +static inline int > >> > +asym_cpu_capacity_classify(struct sched_domain *sd, > >> > + const struct cpumask *cpu_map) > >> > +{ > >> > + int sd_asym_flags = SD_ASYM_CPUCAPACITY | SD_ASYM_CPUCAPACITY_FULL; > >> > + struct asym_cap_data *entry; > >> > + int asym_cap_count = 0; > >> > + > >> > + if (list_is_singular(&asym_cap_list)) > >> > + goto leave; > >> > + > >> > + list_for_each_entry(entry, &asym_cap_list, link) { > >> > + if (cpumask_intersects(sched_domain_span(sd), entry->cpu_mask)) { > >> > + ++asym_cap_count; > >> > + } else { > >> > + /* > >> > + * CPUs with given capacity might be offline > >> > + * so make sure this is not the case > >> > + */ > >> > + if (cpumask_intersects(entry->cpu_mask, cpu_map)) { > >> > + sd_asym_flags &= ~SD_ASYM_CPUCAPACITY_FULL; > >> > + if (asym_cap_count > 1) > >> > + break; > >> > + } > >> > >> Readability nit: That could be made into an else if (). > > It could but then this way the -comment- gets more exposed. > > But that might be my personal perception so I can change that. > > As always those are quite subjective! Methink something like this would > still draw attention to the offline case: > > /* > * Count how many unique capacities this domain covers. If a > * capacity isn't covered, we need to check if any CPU with > * that capacity is actually online, otherwise it can be > * ignored. > */ > if (cpumask_intersects(sched_domain_span(sd), entry->cpu_mask)) { > ++asym_cap_count; > } else if (cpumask_intersects(entry->cpu_mask, cpu_map)) { > sd_asym_flags &= ~SD_ASYM_CPUCAPACITY_FULL; > if (asym_cap_count > 1) > break; > } Noted. Will wait for some more comments before sending out 'polished' version. --- BR B.