linux-kernel - Re: [PATCH 12/49] perf: replace bitmap_weight with bitmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Ygbv8p5Q/X3NJXqf@yury-laptop>
Date:   Fri, 11 Feb 2022 15:23:30 -0800
From:   Yury Norov <yury.norov@...il.com>
To:     Christophe JAILLET <christophe.jaillet@...adoo.fr>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Michał Mirosław <mirq-linux@...e.qmqm.pl>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        David Laight <David.Laight@...lab.com>,
        Joe Perches <joe@...ches.com>, Dennis Zhou <dennis@...nel.org>,
        Emil Renner Berthing <kernel@...il.dk>,
        Nicholas Piggin <npiggin@...il.com>,
        Matti Vaittinen <matti.vaittinen@...rohmeurope.com>,
        Alexey Klimov <aklimov@...hat.com>,
        linux-kernel@...r.kernel.org, Will Deacon <will@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Shaokun Zhang <zhangshaokun@...ilicon.com>,
        Qi Liu <liuqi115@...wei.com>,
        Khuong Dinh <khuong@...amperecomputing.com>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 12/49] perf: replace bitmap_weight with bitmap_empty
 where appropriate

On Fri, Feb 11, 2022 at 06:27:56PM +0100, Christophe JAILLET wrote:
> Le 10/02/2022 à 23:48, Yury Norov a écrit :
> > In some places, drivers/perf code calls bitmap_weight() to check if any
> > bit of a given bitmap is set. It's better to use bitmap_empty() in that
> > case because bitmap_empty() stops traversing the bitmap as soon as it
> > finds first set bit, while bitmap_weight() counts all bits unconditionally.
> > 
> > Signed-off-by: Yury Norov <yury.norov@...il.com>
> > ---
> >   drivers/perf/arm-cci.c                   | 2 +-
> >   drivers/perf/arm_pmu.c                   | 4 ++--
> >   drivers/perf/hisilicon/hisi_uncore_pmu.c | 2 +-
> >   drivers/perf/xgene_pmu.c                 | 2 +-
> >   4 files changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/perf/arm-cci.c b/drivers/perf/arm-cci.c
> > index 54aca3a62814..96e09fa40909 100644
> > --- a/drivers/perf/arm-cci.c
> > +++ b/drivers/perf/arm-cci.c
> > @@ -1096,7 +1096,7 @@ static void cci_pmu_enable(struct pmu *pmu)
> >   {
> >   	struct cci_pmu *cci_pmu = to_cci_pmu(pmu);
> >   	struct cci_pmu_hw_events *hw_events = &cci_pmu->hw_events;
> > -	int enabled = bitmap_weight(hw_events->used_mask, cci_pmu->num_cntrs);
> > +	bool enabled = !bitmap_empty(hw_events->used_mask, cci_pmu->num_cntrs);
> >   	unsigned long flags;
> >   	if (!enabled)
> > diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> > index 295cc7952d0e..a31b302b0ade 100644
> > --- a/drivers/perf/arm_pmu.c
> > +++ b/drivers/perf/arm_pmu.c
> > @@ -524,7 +524,7 @@ static void armpmu_enable(struct pmu *pmu)
> >   {
> >   	struct arm_pmu *armpmu = to_arm_pmu(pmu);
> >   	struct pmu_hw_events *hw_events = this_cpu_ptr(armpmu->hw_events);
> > -	int enabled = bitmap_weight(hw_events->used_mask, armpmu->num_events);
> > +	bool enabled = !bitmap_empty(hw_events->used_mask, armpmu->num_events);
> >   	/* For task-bound events we may be called on other CPUs */
> >   	if (!cpumask_test_cpu(smp_processor_id(), &armpmu->supported_cpus))
> > @@ -785,7 +785,7 @@ static int cpu_pm_pmu_notify(struct notifier_block *b, unsigned long cmd,
> >   {
> >   	struct arm_pmu *armpmu = container_of(b, struct arm_pmu, cpu_pm_nb);
> >   	struct pmu_hw_events *hw_events = this_cpu_ptr(armpmu->hw_events);
> > -	int enabled = bitmap_weight(hw_events->used_mask, armpmu->num_events);
> > +	bool enabled = !bitmap_empty(hw_events->used_mask, armpmu->num_events);
> >   	if (!cpumask_test_cpu(smp_processor_id(), &armpmu->supported_cpus))
> >   		return NOTIFY_DONE;
> > diff --git a/drivers/perf/hisilicon/hisi_uncore_pmu.c b/drivers/perf/hisilicon/hisi_uncore_pmu.c
> > index a738aeab5c04..358e4e284a62 100644
> > --- a/drivers/perf/hisilicon/hisi_uncore_pmu.c
> > +++ b/drivers/perf/hisilicon/hisi_uncore_pmu.c
> > @@ -393,7 +393,7 @@ EXPORT_SYMBOL_GPL(hisi_uncore_pmu_read);
> >   void hisi_uncore_pmu_enable(struct pmu *pmu)
> >   {
> >   	struct hisi_pmu *hisi_pmu = to_hisi_pmu(pmu);
> > -	int enabled = bitmap_weight(hisi_pmu->pmu_events.used_mask,
> > +	bool enabled = !bitmap_empty(hisi_pmu->pmu_events.used_mask,
> >   				    hisi_pmu->num_counters);
> >   	if (!enabled)
> > diff --git a/drivers/perf/xgene_pmu.c b/drivers/perf/xgene_pmu.c
> > index 5283608dc055..0c32dffc7ede 100644
> > --- a/drivers/perf/xgene_pmu.c
> > +++ b/drivers/perf/xgene_pmu.c
> > @@ -867,7 +867,7 @@ static void xgene_perf_pmu_enable(struct pmu *pmu)
> >   {
> >   	struct xgene_pmu_dev *pmu_dev = to_pmu_dev(pmu);
> >   	struct xgene_pmu *xgene_pmu = pmu_dev->parent;
> > -	int enabled = bitmap_weight(pmu_dev->cntr_assign_mask,
> > +	bool enabled = !bitmap_empty(pmu_dev->cntr_assign_mask,
> >   			pmu_dev->max_counters);
> 
> Would it make sense to call it 'disabled', remove the "!"...
> 
> >   	if (!enabled)
> ... and 'if (disabled)' here?

People like positive names (as I do):
        $ git grep bool | grep "= \!" | grep -v "= \!\!" | wc -l
        334

And probably authors chose positive name in this case for a reason.

Replacing 'enabled' with 'disabled' just to avoid negation will add
absolutely nothing to performance, neither to readability. But noise
level of this and other patches will increase - just for nothing.

For me it sounds like total negative commitment.

Thanks,
Yury