All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yury Norov <yury.norov@gmail.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Gabriele Monaco <gmonaco@redhat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Michael Jeanson <mjeanson@efficios.com>,
	Jens Axboe <axboe@kernel.dk>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	"Gautham R. Shenoy" <gautham.shenoy@amd.com>,
	Florian Weimer <fweimer@redhat.com>,
	Tim Chen <tim.c.chen@intel.com>,
	TCMalloc Team <tcmalloc-eng@google.com>
Subject: Re: [patch 07/19] cpumask: Introduce cpumask_or_weight()
Date: Wed, 15 Oct 2025 14:06:00 -0400	[thread overview]
Message-ID: <aO_iiKKVyKSlXeF2@yury> (raw)
In-Reply-To: <aO_c3lTmvJyzsOdE@yury>

On Wed, Oct 15, 2025 at 01:41:50PM -0400, Yury Norov wrote:
> Hi Tomas,
> 
> On Wed, Oct 15, 2025 at 07:29:36PM +0200, Thomas Gleixner wrote:
> > CID management OR's two cpumasks and then calculates the weight on the
> > result. That's inefficient as that has to walk the same stuff twice. As
> > this is done with runqueue lock held, there is a real benefit of speeding
> > this up.
> > 
> > Provide cpumask_or_weight() and the corresponding bitmap functions which
> > return the weight of the OR result right away.
> > 
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > Cc: Yury Norov <yury.norov@gmail.com>
> > ---
> >  include/linux/bitmap.h  |   15 +++++++++++++++
> >  include/linux/cpumask.h |   16 ++++++++++++++++
> >  lib/bitmap.c            |   17 +++++++++++++++++
> >  3 files changed, 48 insertions(+)
> > 
> > --- a/include/linux/bitmap.h
> > +++ b/include/linux/bitmap.h
> > @@ -45,6 +45,7 @@ struct device;
> >   *  bitmap_copy(dst, src, nbits)                *dst = *src
> >   *  bitmap_and(dst, src1, src2, nbits)          *dst = *src1 & *src2
> >   *  bitmap_or(dst, src1, src2, nbits)           *dst = *src1 | *src2
> > + *  bitmap_or_weight(dst, src1, src2, nbits)    *dst = *src1 | *src2. Returns Hamming Weight of dst
> >   *  bitmap_xor(dst, src1, src2, nbits)          *dst = *src1 ^ *src2
> >   *  bitmap_andnot(dst, src1, src2, nbits)       *dst = *src1 & ~(*src2)
> >   *  bitmap_complement(dst, src, nbits)          *dst = ~(*src)
> > @@ -165,6 +166,8 @@ bool __bitmap_and(unsigned long *dst, co
> >  		 const unsigned long *bitmap2, unsigned int nbits);
> >  void __bitmap_or(unsigned long *dst, const unsigned long *bitmap1,
> >  		 const unsigned long *bitmap2, unsigned int nbits);
> > +unsigned int __bitmap_or_weight(unsigned long *dst, const unsigned long *bitmap1,
> > +				const unsigned long *bitmap2, unsigned int nbits);
> >  void __bitmap_xor(unsigned long *dst, const unsigned long *bitmap1,
> >  		  const unsigned long *bitmap2, unsigned int nbits);
> >  bool __bitmap_andnot(unsigned long *dst, const unsigned long *bitmap1,
> > @@ -338,6 +341,18 @@ void bitmap_or(unsigned long *dst, const
> >  }
> >  
> >  static __always_inline
> > +unsigned int bitmap_or_weight(unsigned long *dst, const unsigned long *src1,
> > +			      const unsigned long *src2, unsigned int nbits)
> > +{
> > +	if (small_const_nbits(nbits)) {
> > +		*dst = *src1 | *src2;
> > +		return hweight_long(*dst & BITMAP_LAST_WORD_MASK(nbits));
> > +	} else {
> > +		return __bitmap_or_weight(dst, src1, src2, nbits);
> > +	}
> > +}
> > +
> > +static __always_inline
> >  void bitmap_xor(unsigned long *dst, const unsigned long *src1,
> >  		const unsigned long *src2, unsigned int nbits)
> >  {
> > --- a/include/linux/cpumask.h
> > +++ b/include/linux/cpumask.h
> > @@ -729,6 +729,22 @@ void cpumask_or(struct cpumask *dstp, co
> >  }
> >  
> >  /**
> > + * cpumask_or_weight - *dstp = *src1p | *src2p and return the weight of the result
> > + * @dstp: the cpumask result
> > + * @src1p: the first input
> > + * @src2p: the second input
> > + *
> > + * Return: The number of bits set in the resulting cpumask @dstp
> > + */
> > +static __always_inline
> > +unsigned int cpumask_or_weight(struct cpumask *dstp, const struct cpumask *src1p,
> > +			       const struct cpumask *src2p)
> > +{
> > +	return bitmap_or_weight(cpumask_bits(dstp), cpumask_bits(src1p),
> > +				cpumask_bits(src2p), small_cpumask_bits);
> > +}
> > +
> > +/**
> >   * cpumask_xor - *dstp = *src1p ^ *src2p
> >   * @dstp: the cpumask result
> >   * @src1p: the first input
> > --- a/lib/bitmap.c
> > +++ b/lib/bitmap.c
> > @@ -253,6 +253,23 @@ void __bitmap_or(unsigned long *dst, con
> >  }
> >  EXPORT_SYMBOL(__bitmap_or);
> >  
> > +unsigned int __bitmap_or_weight(unsigned long *dst, const unsigned long *bitmap1,
> > +				const unsigned long *bitmap2, unsigned int bits)
> > +{
> > +	unsigned int k, w = 0;
> > +
> > +	for (k = 0; k < bits / BITS_PER_LONG; k++) {
> > +		dst[k] = bitmap1[k] | bitmap2[k];
> > +		w += hweight_long(dst[k]);
> > +	}
> > +
> > +	if (bits % BITS_PER_LONG) {
> > +		dst[k] = bitmap1[k] | bitmap2[k];
> > +		w += hweight_long(dst[k] & BITMAP_LAST_WORD_MASK(bits));
> > +	}
> > +	return w;
> > +}
> 
> We've got bitmap_weight_and() and bitmap_weight_andnot() already. Can
> you align naming with the existing scheme: bitmap_weight_or().
> 
> Also, for outline implementation, can you employ the BITMAP_WEIGHT()
> macro?

Ok, I see now. You want to do a regular cpumask_or(), but return the
hweight() of the result, instead of a boolean.

The cpumask_or_weight() may be really confused with cpumask_weight_or().
Can you try considering a different naming? (I am seemingly can't.)

Can you describe the performance impact you've mentioned in the commit
message in more details?

Anyways, for the approach:

Acked-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>

  reply	other threads:[~2025-10-15 18:06 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-15 17:29 [patch 00/19] sched: Rewrite MM CID management Thomas Gleixner
2025-10-15 17:29 ` [patch 01/19] sched/mmcid: Revert the complex " Thomas Gleixner
2025-10-15 17:29 ` [patch 02/19] sched/mmcid: Use proper data structures Thomas Gleixner
2025-10-15 17:29 ` [patch 03/19] sched/mmcid: Cacheline align MM CID storage Thomas Gleixner
2025-10-15 17:29 ` [patch 04/19] sched: Fixup whitespace damage Thomas Gleixner
2025-10-15 17:29 ` [patch 05/19] sched/mmcid: Move scheduler code out of global header Thomas Gleixner
2025-10-15 17:29 ` [patch 06/19] sched/mmcid: Prevent pointless work in mm_update_cpus_allowed() Thomas Gleixner
2025-10-17 11:12   ` Peter Zijlstra
2025-10-17 12:49     ` Thomas Gleixner
2025-10-17 17:58       ` Peter Zijlstra
2025-10-17 18:19         ` Peter Zijlstra
2025-10-19 20:32           ` Thomas Gleixner
2025-10-20  8:22             ` Peter Zijlstra
2025-10-21 18:25               ` Thomas Gleixner
2025-10-15 17:29 ` [patch 07/19] cpumask: Introduce cpumask_or_weight() Thomas Gleixner
2025-10-15 17:41   ` Yury Norov
2025-10-15 18:06     ` Yury Norov [this message]
2025-10-21 20:21       ` Thomas Gleixner
2025-10-21 19:34     ` Thomas Gleixner
2025-10-15 17:29 ` [patch 08/19] sched/mmcid: Use cpumask_or_weight() Thomas Gleixner
2025-10-15 17:29 ` [patch 09/19] sched/mmcid: Convert mm CID mask to a bitmap Thomas Gleixner
2025-10-15 17:29 ` [patch 10/19] signal: Move MMCID exit out of sighand lock Thomas Gleixner
2025-10-15 17:29 ` [patch 11/19] sched/mmcid: Move initialization out of line Thomas Gleixner
2025-10-15 17:29 ` [patch 12/19] sched/mmcid: Provide precomputed maximal value Thomas Gleixner
2025-10-15 17:29 ` [patch 13/19] sched/mmcid: Serialize sched_mm_cid_fork()/exit() with a mutex Thomas Gleixner
2025-10-15 17:29 ` [patch 14/19] sched/mmcid: Introduce per task/CPU ownership infrastrcuture Thomas Gleixner
2025-10-15 17:29 ` [patch 15/19] sched/mmcid: Provide new scheduler CID mechanism Thomas Gleixner
2025-10-15 17:29 ` [patch 16/19] sched/mmcid: Provide CID ownership mode fixup functions Thomas Gleixner
2025-10-20  6:34   ` Thomas Gleixner
2025-10-20  9:13   ` Peter Zijlstra
2025-10-20  9:16   ` Peter Zijlstra
2025-10-20  9:27   ` Peter Zijlstra
2025-10-21 18:27     ` Thomas Gleixner
2025-10-15 17:29 ` [patch 17/19] irqwork: Move data struct to a types header Thomas Gleixner
2025-10-15 17:29 ` [patch 18/19] sched/mmcid: Implement deferred mode change Thomas Gleixner
2025-10-15 17:30 ` [patch 19/19] sched/mmcid: Switch over to the new mechanism Thomas Gleixner
2025-10-17  7:09 ` [patch 00/19] sched: Rewrite MM CID management Thomas Gleixner
2025-10-17 11:31 ` Florian Weimer
2025-10-17 12:56   ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aO_iiKKVyKSlXeF2@yury \
    --to=yury.norov@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=fweimer@redhat.com \
    --cc=gautham.shenoy@amd.com \
    --cc=gmonaco@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mjeanson@efficios.com \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tcmalloc-eng@google.com \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.