Message-Id: <20250226123851.a50e727d0a1bfe639ece4a72@linux-foundation.org>
Date: Wed, 26 Feb 2025 12:38:51 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Mark Brown <broonie@...nel.org>
Cc: Easwar Hariharan <eahariha@...ux.microsoft.com>, Yaron Avizrat
 <yaron.avizrat@...el.com>, Oded Gabbay <ogabbay@...nel.org>, Julia Lawall
 <Julia.Lawall@...ia.fr>, Nicolas Palix <nicolas.palix@...g.fr>, James Smart
 <james.smart@...adcom.com>, Dick Kennedy <dick.kennedy@...adcom.com>,
 "James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
 "Martin K. Petersen" <martin.petersen@...cle.com>, Jaroslav Kysela
 <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>, Chris Mason <clm@...com>,
 Josef Bacik <josef@...icpanda.com>, David Sterba <dsterba@...e.com>, Ilya
 Dryomov <idryomov@...il.com>, Dongsheng Yang <dongsheng.yang@...ystack.cn>,
 Jens Axboe <axboe@...nel.dk>, Xiubo Li <xiubli@...hat.com>, Damien Le Moal
 <dlemoal@...nel.org>, Niklas Cassel <cassel@...nel.org>, Carlos Maiolino
 <cem@...nel.org>, "Darrick J. Wong" <djwong@...nel.org>, Sebastian Reichel
 <sre@...nel.org>, Keith Busch <kbusch@...nel.org>, Christoph Hellwig
 <hch@....de>, Sagi Grimberg <sagi@...mberg.me>, Frank Li
 <Frank.Li@....com>, Shawn Guo <shawnguo@...nel.org>, Sascha Hauer
 <s.hauer@...gutronix.de>, Pengutronix Kernel Team <kernel@...gutronix.de>,
 Fabio Estevam <festevam@...il.com>, Shyam Sundar S K
 <Shyam-sundar.S-k@....com>, Hans de Goede <hdegoede@...hat.com>, Ilpo
 Järvinen <ilpo.jarvinen@...ux.intel.com>, Henrique de
 Moraes Holschuh <hmh@....eng.br>, Selvin Xavier
 <selvin.xavier@...adcom.com>, Kalesh AP
 <kalesh-anakkur.purayil@...adcom.com>, Jason Gunthorpe <jgg@...pe.ca>, Leon
 Romanovsky <leon@...nel.org>, cocci@...ia.fr, linux-kernel@...r.kernel.org,
 linux-scsi@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 linux-sound@...r.kernel.org, linux-btrfs@...r.kernel.org,
 ceph-devel@...r.kernel.org, linux-block@...r.kernel.org,
 linux-ide@...r.kernel.org, linux-xfs@...r.kernel.org,
 linux-pm@...r.kernel.org, linux-nvme@...ts.infradead.org,
 linux-spi@...r.kernel.org, imx@...ts.linux.dev,
 linux-arm-kernel@...ts.infradead.org, platform-driver-x86@...r.kernel.org,
 ibm-acpi-devel@...ts.sourceforge.net, linux-rdma@...r.kernel.org, Takashi
 Iwai <tiwai@...e.de>, Carlos Maiolino <cmaiolino@...hat.com>
Subject: Re: [PATCH v3 00/16] Converge on using secs_to_jiffies() part two

On Wed, 26 Feb 2025 11:29:53 +0000 Mark Brown <broonie@...nel.org> wrote:

> On Tue, Feb 25, 2025 at 08:17:14PM +0000, Easwar Hariharan wrote:
> > This is the second series (part 1*) that converts users of msecs_to_jiffies() that
> > either use the multiply pattern of either of:
> > - msecs_to_jiffies(N*1000) or
> > - msecs_to_jiffies(N*MSEC_PER_SEC)
> > 
> > where N is a constant or an expression, to avoid the multiplication.
> 
> Please don't combine patches for multiple subsystems into a single
> series if there's no dependencies between them, it just creates
> confusion about how things get merged, problems for tooling and makes
> everything more noisy.  It's best to split things up per subsystem in
> that case.

I asked for this.  I'll merge everything, spend a few weeks gathering
up maintainer acks.  Anything which a subsystem maintainer merges will
be reported by Stephen and I'll drop that particular patch.

This way, nothing gets lost.  I take this approach often and it works.

If these were sent as a bunch of individual patches then it would be up
to the sender to keep track of what has been merged and what hasn't. 
That person will be resending some stragglers many times.  Until they
give up and some patches get permanently lost.

Scale all that across many senders and the whole process becomes costly
and unreliable.  Whereas centralizing it on akpm is more efficient,
more reliable, more scalable, lower latency and less frustrating for
senders.

Powered by blists - more mailing lists