Re: [PATCHv3] lib/ratelimit: Lockless ratelimiting

2018-08-30 Thread Petr Mladek
On Tue 2018-08-21 00:14:35, Dmitry Safonov wrote: > Hi Petr, thanks for review, > > On Wed, 2018-08-15 at 17:10 +0200, Petr Mladek wrote: > > On Tue 2018-07-03 23:56:28, Dmitry Safonov wrote: > > > Currently ratelimit_state is protected with spin_lock. If the .lock > > > is > > > taken at the

Re: [PATCHv3] lib/ratelimit: Lockless ratelimiting

2018-08-21 Thread Dmitry Safonov
Hi Petr, thanks for review, On Wed, 2018-08-15 at 17:10 +0200, Petr Mladek wrote: > On Tue 2018-07-03 23:56:28, Dmitry Safonov wrote: > > Currently ratelimit_state is protected with spin_lock. If the .lock > > is > > taken at the moment of ___ratelimit() call, the message is > > suppressed to > >

Re: [PATCHv3] lib/ratelimit: Lockless ratelimiting

2018-08-16 Thread Petr Mladek
On Tue 2018-07-03 23:56:28, Dmitry Safonov wrote: > Currently ratelimit_state is protected with spin_lock. If the .lock is > taken at the moment of ___ratelimit() call, the message is suppressed to > make ratelimiting robust. > > That results in the following issue issue: > CPU0

Re: [PATCHv3] lib/ratelimit: Lockless ratelimiting

2018-08-03 Thread Dmitry Safonov
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(>lock, flags)) { > atomic_inc(>missed); >

Re: [PATCHv3] lib/ratelimit: Lockless ratelimiting

2018-08-01 Thread Steven Rostedt
On Fri, 20 Jul 2018 16:33:36 +0100 Dmitry Safonov wrote: > On Fri, 2018-07-20 at 17:09 +0200, Petr Mladek wrote: > > > > On Tue, 2018-07-03 at 23:56 +0100, Dmitry Safonov wrote: > > > > > Currently ratelimit_state is protected with spin_lock. If the > > > > > .lock > > > > > is > > > > > taken

Re: [PATCHv3] lib/ratelimit: Lockless ratelimiting

2018-07-23 Thread Petr Mladek
On Wed 2018-07-18 19:49:10, Andy Shevchenko wrote: > On Tue, Jul 17, 2018 at 3:59 AM, Dmitry Safonov wrote: > > I would be glad if someone helps/bothers to review the change :C > > > > Perhaps Petr and / or Steven can help you. > > Thanks, > > Dmitry > > > > On Tue, 2018-07-03 at 23:56 +0100,

Re: [PATCHv3] lib/ratelimit: Lockless ratelimiting

2018-07-23 Thread Dmitry Safonov
On Fri, 2018-07-20 at 17:09 +0200, Petr Mladek wrote: > > > On Tue, 2018-07-03 at 23:56 +0100, Dmitry Safonov wrote: > > > > Currently ratelimit_state is protected with spin_lock. If the > > > > .lock > > > > is > > > > taken at the moment of ___ratelimit() call, the message is > > > > suppressed

Re: [PATCHv3] lib/ratelimit: Lockless ratelimiting

2018-07-18 Thread Andy Shevchenko
On Tue, Jul 17, 2018 at 3:59 AM, Dmitry Safonov wrote: > I would be glad if someone helps/bothers to review the change :C > Perhaps Petr and / or Steven can help you. > Thanks, > Dmitry > > On Tue, 2018-07-03 at 23:56 +0100, Dmitry Safonov wrote: >> Currently ratelimit_state is protected with

Re: [PATCHv3] lib/ratelimit: Lockless ratelimiting

2018-07-17 Thread Dmitry Safonov
I would be glad if someone helps/bothers to review the change :C Thanks, Dmitry On Tue, 2018-07-03 at 23:56 +0100, Dmitry Safonov wrote: > Currently ratelimit_state is protected with spin_lock. If the .lock > is > taken at the moment of ___ratelimit() call, the message is suppressed > to > make

[PATCHv3] lib/ratelimit: Lockless ratelimiting

2018-07-04 Thread Dmitry Safonov
Currently ratelimit_state is protected with spin_lock. If the .lock is taken at the moment of ___ratelimit() call, the message is suppressed to make ratelimiting robust. That results in the following issue issue: CPU0 CPU1 --