Re: [PATCH] mISDN: hfcsusb: Optimize performance by replacing rw_lock with spinlock

[Simon Horman <horms@kernel.org>]

On Thu, Mar 27, 2025 at 11:28:25PM +0800, Yu-Chun Lin wrote:
> On Mon, Mar 24, 2025 at 02:21:15PM +0000, Simon Horman wrote:
> > On Sat, Mar 22, 2025 at 01:20:24AM +0800, Yu-Chun Lin wrote:
> > > The 'HFClock', an rwlock, is only used by writers, making it functionally
> > > equivalent to a spinlock.
> > > 
> > > According to Documentation/locking/spinlocks.rst:
> > > 
> > > "Reader-writer locks require more atomic memory operations than simple
> > > spinlocks. Unless the reader critical section is long, you are better
> > > off just using spinlocks."
> > > 
> > > Since read_lock() is never called, switching to a spinlock reduces
> > > overhead and improves efficiency.
> > > 
> > > Signed-off-by: Yu-Chun Lin <eleanor15x@gmail.com>
> > > ---
> > > Build tested only, as I don't have the hardware. 
> > > Ensured all rw_lock -> spinlock conversions are complete, and replacing
> > > rw_lock with spinlock should always be safe.
> > > 
> > >  drivers/isdn/hardware/mISDN/hfcsusb.c | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > Hi Yu-Chun Lin,
> > 
> > Thanks for your patch.
> > 
> > Unfortunately I think it would be best to leave this rather old
> > and probably little used driver as-is in this regard unless there
> > is a demonstrable improvement on real hardware.
> > 
> > Otherwise the small risk of regression and overhead of driver
> > changes seems to outweigh the theoretical benefit.
> 
> Thank you for your feedback.
> 
> I noticed that the MAINTAINERS file lists a maintainer for ISDN, so I
> was wondering if he might have access to the necessary hardware for
> quick testing.
> 
> Since I am new to the kernel, I would like to ask if there have been
> any past cases or experiences where similar changes were considered
> unsafe. Additionally, I have seen instances where the crypto maintainer
> accepted similar patches even without hardware testing. [1]
> 
> [1]: https://lore.kernel.org/lkml/20240823183856.561166-1-visitorckw@gmail.com/

I think it is a judgement call, and certainly the crypto maintainer is
free to make their own call. But in this case I do lean towards leaving
the code unchanged in the absence of hardware testing.