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

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 <redacted>
---
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(-)

diff --git a/drivers/isdn/hardware/mISDN/hfcsusb.c b/drivers/isdn/hardware/mISDN/hfcsusb.c
index e54419a4e731..5041d635ef7f 100644
--- a/drivers/isdn/hardware/mISDN/hfcsusb.c
+++ b/drivers/isdn/hardware/mISDN/hfcsusb.c

@@ -27,7 +27,7 @@ static unsigned int debug;
 static int poll = DEFAULT_TRANSP_BURST_SZ;
 
 static LIST_HEAD(HFClist);
-static DEFINE_RWLOCK(HFClock);
+static DEFINE_SPINLOCK(HFClock);
 
 
 MODULE_AUTHOR("Martin Bachem");

@@ -1895,9 +1895,9 @@ setup_instance(struct hfcsusb *hw, struct device *parent)
 		goto out;
 
 	hfcsusb_cnt++;
-	write_lock_irqsave(&HFClock, flags);
+	spin_lock_irqsave(&HFClock, flags);
 	list_add_tail(&hw->list, &HFClist);
-	write_unlock_irqrestore(&HFClock, flags);
+	spin_unlock_irqrestore(&HFClock, flags);
 	return 0;
 
 out:

-- 
2.43.0

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 <redacted>
---
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.

-- 
pw-bot: deferred

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:

quoted

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 <redacted>
---
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/

Regards,
Yu-Chun

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:

quoted

On Sat, Mar 22, 2025 at 01:20:24AM +0800, Yu-Chun Lin wrote:

quoted

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 <redacted>
---
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.