Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp5087176pxb; Wed, 26 Jan 2022 04:37:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJz2o7+pe3/Pm0B6fY35AOdQPx7lguy6nhRURZCoEezvHyaKrW8/XA1MojO7+Ds4cvEN19ue X-Received: by 2002:a17:903:1c8:b0:14b:6b63:b3fa with SMTP id e8-20020a17090301c800b0014b6b63b3famr9044478plh.156.1643200663410; Wed, 26 Jan 2022 04:37:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643200663; cv=none; d=google.com; s=arc-20160816; b=0t4ilRh+WpxSmAZDZ5qDShLtvnIX3ZLbCpsJMCGDWEKkTcj8grR1JSSU6zJc6zRxmj Jn0L9IzKSS5q8uVGiMJaXsFWu6MYdtHXGVS5iQtT5TWq63DA7ZhbYdNP1ktL+kXCiYiZ d6O5hkyA7cmebhtc6ipa2dJ5k3Psb7p0IBg3vBF0uJWpkKF8Uv5KcS11iiSBwdpEvyTV OC+npOrNWaa1RWFfA4K7/bje5VPS6hyoY69BrNR0tPH3nK3BWUgC5L+LuYNmcFe0GkAT pocqCs1KOToCbo0NWXJ9osjSDd6hCEKrdHRlflaZTFxqWKGr7KJ0mVHiwPB7j+SQnT3e tU8A== 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=ZiD+gfGULUePol9enoFFTPd7AmIreHB5h2FwvDcgVRE=; b=fepy8IkDodivxJTCu4UpLHQCCrfdwLbt7vmVLl9VMudqgXFQOCKtzz6/26QkfdHxLF a5OIuYYVAG73VLu8OorFDKLc77a7Yw6K9HgzxNnqRIvTt0xQ2iVKRQAI8vqTFsA0djNP HA3YZF686vaZjtecXEiBwx+6fbvP3bN3zsXy/TBQNJr9HvGApGhdWlqU7KURuWk9U4kD JPy7HXnq0ZGDd/Gehh72UltykjcsMzFXD2hwdREXQnzvqAyWcSlv1ILWhWCWyhprIac5 9ou6V++1l+KWtiaxc8VV5sZpaRZq3ha22qk8XKVIa+ixxhdYE/GWbZMbGih6sK1dMAdP F9Dw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ay11si2493371pjb.100.2022.01.26.04.37.29; Wed, 26 Jan 2022 04:37:43 -0800 (PST) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234429AbiAYWvE (ORCPT + 99 others); Tue, 25 Jan 2022 17:51:04 -0500 Received: from elvis.franken.de ([193.175.24.41]:40123 "EHLO elvis.franken.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234546AbiAYWuZ (ORCPT ); Tue, 25 Jan 2022 17:50:25 -0500 Received: from uucp (helo=alpha) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1nCUdn-00055K-00; Tue, 25 Jan 2022 23:50:19 +0100 Received: by alpha.franken.de (Postfix, from userid 1000) id C55C2C10E8; Tue, 25 Jan 2022 20:05:31 +0100 (CET) Date: Tue, 25 Jan 2022 20:05:31 +0100 From: Thomas Bogendoerfer To: Yury Norov Cc: Andy Shevchenko , Rasmus Villemoes , Andrew Morton , =?utf-8?B?TWljaGHFgiBNaXJvc8WCYXc=?= , Greg Kroah-Hartman , Peter Zijlstra , David Laight , Joe Perches , Dennis Zhou , Emil Renner Berthing , Nicholas Piggin , Matti Vaittinen , Alexey Klimov , linux-kernel@vger.kernel.org, Mark Rutland , Marc Zyngier , linux-mips@vger.kernel.org Subject: Re: [PATCH 38/54] arch/mips: replace cpumask_weight with cpumask_weight_{eq, ...} where appropriate Message-ID: <20220125190531.GA31998@alpha.franken.de> References: <20220123183925.1052919-1-yury.norov@gmail.com> <20220123183925.1052919-39-yury.norov@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220123183925.1052919-39-yury.norov@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jan 23, 2022 at 10:39:09AM -0800, Yury Norov wrote: > Mips code uses calls cpumask_weight() to compare the weight of > cpumask with a given number. We can do it more efficiently with > cpumask_weight_{eq, ...} because conditional cpumask_weight may stop > traversing the cpumask earlier, as soon as condition is met. > > Signed-off-by: Yury Norov > --- > arch/mips/cavium-octeon/octeon-irq.c | 4 ++-- > arch/mips/kernel/crash.c | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/mips/cavium-octeon/octeon-irq.c b/arch/mips/cavium-octeon/octeon-irq.c > index 844f882096e6..914871f15fb7 100644 > --- a/arch/mips/cavium-octeon/octeon-irq.c > +++ b/arch/mips/cavium-octeon/octeon-irq.c > @@ -763,7 +763,7 @@ static void octeon_irq_cpu_offline_ciu(struct irq_data *data) > if (!cpumask_test_cpu(cpu, mask)) > return; > > - if (cpumask_weight(mask) > 1) { > + if (cpumask_weight_gt(mask, 1)) { > /* > * It has multi CPU affinity, just remove this CPU > * from the affinity set. > @@ -795,7 +795,7 @@ static int octeon_irq_ciu_set_affinity(struct irq_data *data, > * This removes the need to do locking in the .ack/.eoi > * functions. > */ > - if (cpumask_weight(dest) != 1) > + if (!cpumask_weight_eq(dest, 1)) > return -EINVAL; > > if (!enable_one) > diff --git a/arch/mips/kernel/crash.c b/arch/mips/kernel/crash.c > index 81845ba04835..5b690d52491f 100644 > --- a/arch/mips/kernel/crash.c > +++ b/arch/mips/kernel/crash.c > @@ -72,7 +72,7 @@ static void crash_kexec_prepare_cpus(void) > */ > pr_emerg("Sending IPI to other cpus...\n"); > msecs = 10000; > - while ((cpumask_weight(&cpus_in_crash) < ncpus) && (--msecs > 0)) { > + while (cpumask_weight_lt(&cpus_in_crash, ncpus) && (--msecs > 0)) { > cpu_relax(); > mdelay(1); > } > -- > 2.30.2 Acked-by: Thomas Bogendoerfer -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]