All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Yury Norov <yury.norov@gmail.com>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, netdev@vger.kernel.org,
	virtualization@lists.linux.dev, linux-nvme@lists.infradead.org,
	linux-hyperv@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-crypto@vger.kernel.org,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Nicholas Piggin" <npiggin@gmail.com>,
	"Christophe Leroy" <christophe.leroy@csgroup.eu>,
	"Naveen N Rao" <naveen@kernel.org>,
	"Madhavan Srinivasan" <maddy@linux.ibm.com>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>,
	"Sven Schnelle" <svens@linux.ibm.com>,
	"Haren Myneni" <haren@linux.ibm.com>,
	"Rick Lindsley" <ricklind@linux.ibm.com>,
	"Nick Child" <nnac123@linux.ibm.com>,
	"Thomas Falcon" <tlfalcon@linux.ibm.com>,
	"Andrew Lunn" <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"Xuan Zhuo" <xuanzhuo@linux.alibaba.com>,
	"Eugenio Pérez" <eperezma@redhat.com>,
	"Keith Busch" <kbusch@kernel.org>, "Jens Axboe" <axboe@kernel.dk>,
	"Christoph Hellwig" <hch@lst.de>,
	"Sagi Grimberg" <sagi@grimberg.me>,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	"Haiyang Zhang" <haiyangz@microsoft.com>,
	"Wei Liu" <wei.liu@kernel.org>,
	"Dexuan Cui" <decui@microsoft.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Manivannan Sadhasivam" <manivannan.sadhasivam@linaro.org>,
	"Rob Herring" <robh@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"James Smart" <james.smart@broadcom.com>,
	"Dick Kennedy" <dick.kennedy@broadcom.com>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
	"Matt Wu" <wuqiang.matt@bytedance.com>,
	"Steffen Klassert" <steffen.klassert@secunet.com>,
	"Daniel Jordan" <daniel.m.jordan@oracle.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Greg Kurz" <groug@kaod.org>, "Peter Xu" <peterx@redhat.com>,
	"Shrikanth Hegde" <sshegde@linux.ibm.com>,
	"Hendrik Brueckner" <brueckner@linux.ibm.com>
Subject: Re: [PATCH v2 00/13] cpumask: cleanup cpumask_next_wrap() implementation and usage
Date: Mon, 24 Feb 2025 16:18:47 -0500	[thread overview]
Message-ID: <20250224161832-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20250128164646.4009-1-yury.norov@gmail.com>

On Tue, Jan 28, 2025 at 11:46:29AM -0500, Yury Norov wrote:
> cpumask_next_wrap() is overly complicated, comparing to it's generic
> version find_next_bit_wrap(), not mentioning it duplicates the above.
> It roots to the times when the function was used in the implementation
> of for_each_cpu_wrap() iterator. The function has 2 additional parameters
> that were used to catch loop termination condition for the iterator.
> (Although, only one is needed.)
> 
> Since 4fe49b3b97c262 ("lib/bitmap: introduce for_each_set_bit_wrap()
> macro"), for_each_cpu_wrap() is wired to corresponding generic
> wrapping bitmap iterator, and additional complexity of
> cpumask_next_wrap() is not needed anymore.
> 
> All existing users call cpumask_next_wrap() in a manner that makes
> it possible to turn it to a straight and simple alias to
> find_next_bit_wrap().
> 
> This series replaces historical 4-parameter cpumask_next_wrap() with a
> thin 2-parameter wrapper around find_next_bit_wrap().
> 
> Where it's possible to use for_each_cpu_wrap() iterator, the code is
> switched to use it because it's always preferable to use iterators over
> open loops.
> 
> This series touches various scattered subsystems and To-list for the
> whole series is quite a long. To minimize noise, I send cover-letter and
> key patches #5 and 6 to every person involved. All other patches are sent
> individually to those pointed by scripts/get_maintainers.pl.
> 
> I'd like to move the series with my bitmap-for-next branch as a whole.


virtio-net changes are straight-forward, so

Acked-by: Michael S. Tsirkin <mst@redhat.com>


> v1: https://lore.kernel.org/netdev/20241228184949.31582-1-yury.norov@gmail.com/T/
> v2:
>  - rebase on top of today's origin/master;
>  - drop #v1-10: not needed since v6.14 @ Sagi Grinberg;
>  - #2, #3: fix picking next unused CPU @ Nick Child;
>  - fix typos, cleanup comments @ Bjorn Helgaas, Alexander Gordeev;
>  - CC Christoph Hellwig for the whole series.
> 
> Yury Norov (13):
>   objpool: rework objpool_pop()
>   virtio_net: simplify virtnet_set_affinity()
>   ibmvnic: simplify ibmvnic_set_queue_affinity()
>   powerpc/xmon: simplify xmon_batch_next_cpu()
>   cpumask: deprecate cpumask_next_wrap()
>   cpumask: re-introduce cpumask_next{,_and}_wrap()
>   cpumask: use cpumask_next_wrap() where appropriate
>   padata: switch padata_find_next() to using cpumask_next_wrap()
>   s390: switch stop_machine_yield() to using cpumask_next_wrap()
>   scsi: lpfc: switch lpfc_irq_rebalance() to using cpumask_next_wrap()
>   scsi: lpfc: rework lpfc_next_{online,present}_cpu()
>   PCI: hv: Switch hv_compose_multi_msi_req_get_cpu() to using
>     cpumask_next_wrap()
>   cpumask: drop cpumask_next_wrap_old()
> 
>  arch/powerpc/xmon/xmon.c            |  6 +--
>  arch/s390/kernel/processor.c        |  2 +-
>  drivers/net/ethernet/ibm/ibmvnic.c  | 18 +++++---
>  drivers/net/virtio_net.c            | 12 ++---
>  drivers/pci/controller/pci-hyperv.c |  3 +-
>  drivers/scsi/lpfc/lpfc.h            | 23 +++-------
>  drivers/scsi/lpfc/lpfc_init.c       |  2 +-
>  include/linux/cpumask.h             | 69 ++++++++++++++++++++---------
>  include/linux/objpool.h             |  7 ++-
>  kernel/padata.c                     |  2 +-
>  lib/cpumask.c                       | 37 +---------------
>  11 files changed, 81 insertions(+), 100 deletions(-)
> 
> -- 
> 2.43.0


      parent reply	other threads:[~2025-02-24 21:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-28 16:46 [PATCH v2 00/13] cpumask: cleanup cpumask_next_wrap() implementation and usage Yury Norov
2025-01-28 16:46 ` [PATCH v2 01/13] objpool: rework objpool_pop() Yury Norov
2025-01-28 16:46 ` [PATCH v2 02/13] virtio_net: simplify virtnet_set_affinity() Yury Norov
2025-02-05 23:00   ` Nick Child
2025-02-11 13:55     ` Yury Norov
2025-01-28 16:46 ` [PATCH v2 03/13] ibmvnic: simplify ibmvnic_set_queue_affinity() Yury Norov
2025-02-05 23:10   ` Nick Child
2025-01-28 16:46 ` [PATCH v2 04/13] powerpc/xmon: simplify xmon_batch_next_cpu() Yury Norov
2025-01-28 16:46 ` [PATCH v2 05/13] cpumask: deprecate cpumask_next_wrap() Yury Norov
2025-01-28 16:46 ` [PATCH v2 06/13] cpumask: re-introduce cpumask_next{,_and}_wrap() Yury Norov
2025-01-28 16:46 ` [PATCH v2 07/13] cpumask: use cpumask_next_wrap() where appropriate Yury Norov
2025-01-28 16:46 ` [PATCH v2 08/13] padata: switch padata_find_next() to using cpumask_next_wrap() Yury Norov
2025-01-28 16:46 ` [PATCH v2 09/13] s390: switch stop_machine_yield() " Yury Norov
2025-01-28 16:46 ` Yury Norov
2025-01-28 16:46 ` [PATCH v2 11/13] scsi: lpfc: rework lpfc_next_{online,present}_cpu() Yury Norov
2025-01-28 16:46 ` [PATCH v2 12/13] PCI: hv: Switch hv_compose_multi_msi_req_get_cpu() to using cpumask_next_wrap() Yury Norov
2025-01-28 16:46 ` [PATCH v2 13/13] cpumask: drop cpumask_next_wrap_old() Yury Norov
2025-02-24 21:18 ` Michael S. Tsirkin [this message]

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=20250224161832-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=agordeev@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=axboe@kernel.dk \
    --cc=bhelgaas@google.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=brueckner@linux.ibm.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=daniel.m.jordan@oracle.com \
    --cc=davem@davemloft.net \
    --cc=decui@microsoft.com \
    --cc=dick.kennedy@broadcom.com \
    --cc=edumazet@google.com \
    --cc=eperezma@redhat.com \
    --cc=gor@linux.ibm.com \
    --cc=groug@kaod.org \
    --cc=haiyangz@microsoft.com \
    --cc=haren@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=hch@lst.de \
    --cc=james.smart@broadcom.com \
    --cc=jasowang@redhat.com \
    --cc=kbusch@kernel.org \
    --cc=kuba@kernel.org \
    --cc=kw@linux.com \
    --cc=kys@microsoft.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-hyperv@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lpieralisi@kernel.org \
    --cc=maddy@linux.ibm.com \
    --cc=manivannan.sadhasivam@linaro.org \
    --cc=martin.petersen@oracle.com \
    --cc=mpe@ellerman.id.au \
    --cc=naveen@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nnac123@linux.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=peterx@redhat.com \
    --cc=ricklind@linux.ibm.com \
    --cc=robh@kernel.org \
    --cc=sagi@grimberg.me \
    --cc=sshegde@linux.ibm.com \
    --cc=steffen.klassert@secunet.com \
    --cc=svens@linux.ibm.com \
    --cc=tlfalcon@linux.ibm.com \
    --cc=virtualization@lists.linux.dev \
    --cc=wei.liu@kernel.org \
    --cc=wuqiang.matt@bytedance.com \
    --cc=xuanzhuo@linux.alibaba.com \
    --cc=yury.norov@gmail.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.