[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20250418171359.1187719-13-paulmck@kernel.org>
Date: Fri, 18 Apr 2025 10:13:58 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: linux-kernel@...r.kernel.org
Cc: kernel-team@...a.com,
Andrew Morton <akpm@...ux-foundation.org>,
Kuniyuki Iwashima <kuniyu@...zon.com>,
Mateusz Guzik <mjguzik@...il.com>,
Petr Mladek <pmladek@...e.com>,
Steven Rostedt <rostedt@...dmis.org>,
John Ogness <john.ogness@...utronix.de>,
Sergey Senozhatsky <senozhatsky@...omium.org>,
Jon Pan-Doh <pandoh@...gle.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Karolina Stolarek <karolina.stolarek@...cle.com>,
"Paul E. McKenney" <paulmck@...nel.org>
Subject: [PATCH v2 ratelimit 13/14] ratelimit: Avoid atomic decrement if already rate-limited
Currently, if the lock could not be acquired, the code unconditionally
does an atomic decrement on ->rs_n_left, even if that atomic operation
is guaranteed to return a limit-rate verdict. This incurs needless
overhead and also raises the spectre of counter wrap.
Therefore, do the atomic decrement only if there is some chance that
rates won't be limited.
Signed-off-by: Paul E. McKenney <paulmck@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: Mateusz Guzik <mjguzik@...il.com>
Cc: Petr Mladek <pmladek@...e.com>
Cc: Steven Rostedt <rostedt@...dmis.org>
Cc: John Ogness <john.ogness@...utronix.de>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>
---
lib/ratelimit.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/ratelimit.c b/lib/ratelimit.c
index b306e230c56bb..2048f20561f31 100644
--- a/lib/ratelimit.c
+++ b/lib/ratelimit.c
@@ -60,8 +60,10 @@ int ___ratelimit(struct ratelimit_state *rs, const char *func)
unsigned int rs_flags = READ_ONCE(rs->flags);
if (rs_flags & RATELIMIT_INITIALIZED && burst) {
- int n_left;
+ int n_left = atomic_read(&rs->rs_n_left);
+ if (n_left <= 0)
+ return 0;
n_left = atomic_dec_return(&rs->rs_n_left);
if (n_left >= 0)
return 1;
--
2.40.1
Powered by blists - more mailing lists