NetBSD Problem Report #57538

From www@netbsd.org  Sat Jul 22 21:10:28 2023
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 23A161A923E
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 22 Jul 2023 21:10:28 +0000 (UTC)
Message-Id: <20230722211026.991371A9241@mollari.NetBSD.org>
Date: Sat, 22 Jul 2023 21:10:26 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: ptimer_tick and ptimer_intr abuse locks
X-Send-Pr-Version: www-1.0

>Number:         57538
>Category:       kern
>Synopsis:       ptimer_tick and ptimer_intr abuse locks
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jul 22 21:15:00 +0000 2023
>Originator:     Taylor R Campbell
>Release:        current
>Organization:
The NetBSD Timerdation
>Environment:
>Description:
- ptimer_tick takes a global lock on every hardclock tick, and it's the same one on every CPU, probably leading to unnecessary contention.

- ptimer_intr takes a global proc_lock from softint context, which is probably a bad idea (IPL_NONE) and probably also leads to unnecessary contention.

These should maybe have finer-grained locks or per-CPU storage that doesn't require locking.
>How-To-Repeat:
code inspection
>Fix:
Yes please!

Home	PR Database Search