[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1533223155.2679.136.camel@arista.com>
Date: Thu, 02 Aug 2018 16:19:15 +0100
From: Dmitry Safonov <dima@...sta.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Petr Mladek <pmladek@...e.com>,
Andy Shevchenko <andy.shevchenko@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>, David Airlie <airlied@...ux.ie>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
Theodore Ts'o <tytso@....edu>,
Thomas Gleixner <tglx@...utronix.de>,
intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCHv3] lib/ratelimit: Lockless ratelimiting
Hi Steven,
Thanks for your reply,
On Wed, 2018-08-01 at 21:48 -0400, Steven Rostedt wrote:
> I'm just catching up from my vacation. What about making rs->missed
> into an atomic, and have:
>
> if (!raw_spin_trylock_irqsave(&rs->lock, flags)) {
> atomic_inc(&rs->missed);
> return 0;
> }
>
> ?
Uhm. Do you mean as a preparation patch to split this on two patches?
Because it will not solve the issue where one CPU has taken rs->lock,
and is updating rs->printed, checking burst and whatnot; while the
second CPU will loose the message which was even *under* burst limit.
I.e.: there are enough of printk_ratelimit() users in tree and a
message from one can be suppressed, while shouldn't.
> You would also need to do:
>
> if (time_is_before_jiffies(rs->begin + rs->interval)) {
> int missed = atomic_xchg(&rs->missed, 0);
> if (missed) {
>
> So that you don't have a race between checking rs->missed and setting
> it
> to zero.
--
Thanks,
Dmitry
Powered by blists - more mailing lists