[PATCH 12/49] perf: replace bitmap_weight with bitmap_empty where appropriate
Yury Norov
yury.norov at gmail.com
Fri Feb 11 15:23:30 PST 2022
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 at gmail.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
More information about the linux-arm-kernel
mailing list