On August 8, 2018 6:47:16 PM EDT, "Paul E. McKenney"
wrote:
>On Wed, Aug 08, 2018 at 03:15:31PM -0700, Joel Fernandes wrote:
>> On Wed, Aug 8, 2018 at 1:18 PM, Paul E. McKenney
>> wrote:
>> [...]
>> >> >> >> It does start to seem like a show stopper :-(
>> >> >> >
>> >> >> > I suppose that an
On Wed, Aug 08, 2018 at 03:15:31PM -0700, Joel Fernandes wrote:
> On Wed, Aug 8, 2018 at 1:18 PM, Paul E. McKenney
> wrote:
> [...]
> >> >> >> It does start to seem like a show stopper :-(
> >> >> >
> >> >> > I suppose that an srcu_read_lock_nmi() and srcu_read_unlock_nmi()
> >> >> > could
> >> >
On Wed, Aug 8, 2018 at 1:18 PM, Paul E. McKenney
wrote:
[...]
>> >> >> It does start to seem like a show stopper :-(
>> >> >
>> >> > I suppose that an srcu_read_lock_nmi() and srcu_read_unlock_nmi() could
>> >> > be added, which would do atomic ops on sp->sda->srcu_lock_count. Not
>> >> > sure
>
On Wed, Aug 08, 2018 at 12:24:20PM -0700, Joel Fernandes wrote:
> On Wed, Aug 8, 2018 at 7:49 AM, Paul E. McKenney
> wrote:
> [...]
> >
> >> In that case based on what you're saying, the patch I sent to using
> >> different srcu_struct for NMI is still good I guess...
> >
> > As long as you wait f
On Wed, Aug 8, 2018 at 7:49 AM, Paul E. McKenney
wrote:
[...]
>
>> In that case based on what you're saying, the patch I sent to using
>> different srcu_struct for NMI is still good I guess...
>
> As long as you wait for both SRCU grace periods. Hmmm... Maybe that means
> that there is still a u
On Wed, Aug 08, 2018 at 12:24:04PM -0400, Steven Rostedt wrote:
> On Wed, 8 Aug 2018 09:02:43 -0700
> "Paul E. McKenney" wrote:
>
> > > Which leaves us with sparc, arm, mips, sh and powerpc.
> > >
> > > sh is almost dead, and powerpc can be fixed, which I guess leaves us
> > > with sparc, arm an
On Wed, 8 Aug 2018 09:02:43 -0700
"Paul E. McKenney" wrote:
> > Which leaves us with sparc, arm, mips, sh and powerpc.
> >
> > sh is almost dead, and powerpc can be fixed, which I guess leaves us
> > with sparc, arm and mips.
>
> If we want to stick with the current srcu_read_lock() and srcu_
On Wed, Aug 08, 2018 at 11:27:05AM -0400, Steven Rostedt wrote:
> On Wed, 8 Aug 2018 07:42:00 -0700
> "Paul E. McKenney" wrote:
>
> > > There's also a local_inc() if you are using per cpu pointers, that is
> > > suppose to guarantee atomicity for single cpu operations. That's what
> > > the ftrac
On Wed, Aug 08, 2018 at 11:23:09AM -0400, Steven Rostedt wrote:
> On Wed, 8 Aug 2018 08:05:58 -0700
> "Paul E. McKenney" wrote:
>
> > On Wed, Aug 08, 2018 at 10:49:10AM -0400, Steven Rostedt wrote:
> > > On Wed, 8 Aug 2018 07:33:10 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > > > On Wed, A
On Wed, 8 Aug 2018 07:42:00 -0700
"Paul E. McKenney" wrote:
> > There's also a local_inc() if you are using per cpu pointers, that is
> > suppose to guarantee atomicity for single cpu operations. That's what
> > the ftrace ring buffer uses.
>
> Good point, that becomes atomic_long_inc() or equ
On Wed, 8 Aug 2018 08:05:58 -0700
"Paul E. McKenney" wrote:
> On Wed, Aug 08, 2018 at 10:49:10AM -0400, Steven Rostedt wrote:
> > On Wed, 8 Aug 2018 07:33:10 -0700
> > "Paul E. McKenney" wrote:
> >
> > > On Wed, Aug 08, 2018 at 09:07:24AM -0400, Steven Rostedt wrote:
> > > > On Wed, 8 Aug 2
On Wed, Aug 08, 2018 at 10:49:10AM -0400, Steven Rostedt wrote:
> On Wed, 8 Aug 2018 07:33:10 -0700
> "Paul E. McKenney" wrote:
>
> > On Wed, Aug 08, 2018 at 09:07:24AM -0400, Steven Rostedt wrote:
> > > On Wed, 8 Aug 2018 06:03:02 -0700
> > > "Paul E. McKenney" wrote:
> > >
> > > > What's w
On Wed, Aug 08, 2018 at 07:10:53AM -0700, Joel Fernandes wrote:
> On Wed, Aug 8, 2018 at 6:00 AM, Paul E. McKenney
> wrote:
> > On Tue, Aug 07, 2018 at 08:53:54PM -0700, Joel Fernandes wrote:
> >> On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes wrote:
> >> > Hi Steve,
> >> >
> >> > On Tue, Aug 7,
On Wed, 8 Aug 2018 07:33:10 -0700
"Paul E. McKenney" wrote:
> On Wed, Aug 08, 2018 at 09:07:24AM -0400, Steven Rostedt wrote:
> > On Wed, 8 Aug 2018 06:03:02 -0700
> > "Paul E. McKenney" wrote:
> >
> > > What's wrong with a this_cpu_inc()? It's atomic for the CPU. Although
> > > > it wont
On Wed, Aug 08, 2018 at 10:27:00AM -0400, Steven Rostedt wrote:
> On Wed, 8 Aug 2018 06:00:41 -0700
> "Paul E. McKenney" wrote:
> >
> > I suppose that an srcu_read_lock_nmi() and srcu_read_unlock_nmi() could
> > be added, which would do atomic ops on sp->sda->srcu_lock_count. Not sure
> > whethe
On Wed, Aug 08, 2018 at 09:07:24AM -0400, Steven Rostedt wrote:
> On Wed, 8 Aug 2018 06:03:02 -0700
> "Paul E. McKenney" wrote:
>
> > What's wrong with a this_cpu_inc()? It's atomic for the CPU. Although
> > > it wont be atomic for the capture of the idx. But I also don't see
> > > interrupts be
On Wed, 8 Aug 2018 06:00:41 -0700
"Paul E. McKenney" wrote:
>
> I suppose that an srcu_read_lock_nmi() and srcu_read_unlock_nmi() could
> be added, which would do atomic ops on sp->sda->srcu_lock_count. Not sure
> whether this would be fast enough to be useful, but easy to provide:
>
> int __sr
On Wed, Aug 8, 2018 at 6:00 AM, Paul E. McKenney
wrote:
> On Tue, Aug 07, 2018 at 08:53:54PM -0700, Joel Fernandes wrote:
>> On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes wrote:
>> > Hi Steve,
>> >
>> > On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote:
>> [...]
>> >>> @@ -171,8 +174,7 @@ ex
On Wed, 8 Aug 2018 06:03:02 -0700
"Paul E. McKenney" wrote:
> What's wrong with a this_cpu_inc()? It's atomic for the CPU. Although
> > it wont be atomic for the capture of the idx. But I also don't see
> > interrupts being disabled, thus an NMI is no different than any
> > interrupt doing the s
On Wed, Aug 08, 2018 at 08:46:29AM -0400, Steven Rostedt wrote:
> On Tue, 7 Aug 2018 20:53:54 -0700
> Joel Fernandes wrote:
>
>
> > > When I talked to Paul few months ago about SRCU from NMI context, he
> > > mentioned the per-cpu memory operations during srcu_read_lock can be
> > > NMI interrup
On Tue, Aug 07, 2018 at 08:53:54PM -0700, Joel Fernandes wrote:
> On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes wrote:
> > Hi Steve,
> >
> > On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote:
> [...]
> >>> @@ -171,8 +174,7 @@ extern void syscall_unregfunc(void);
> >>> }
On Tue, 7 Aug 2018 20:53:54 -0700
Joel Fernandes wrote:
> > When I talked to Paul few months ago about SRCU from NMI context, he
> > mentioned the per-cpu memory operations during srcu_read_lock can be
> > NMI interrupted, that's why we added that warning.
>
> So I looked more closely, __srcu
On Tue, Aug 7, 2018 at 8:53 PM, Joel Fernandes wrote:
> On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes wrote:
>> Hi Steve,
>>
>> On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote:
> [...]
@@ -171,8 +174,7 @@ extern void syscall_unregfunc(void);
} while ((++it_f
On Tue, Aug 7, 2018 at 8:44 PM, Joel Fernandes wrote:
> Hi Steve,
>
> On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote:
[...]
>>> @@ -171,8 +174,7 @@ extern void syscall_unregfunc(void);
>>> } while ((++it_func_ptr)->func);\
>>> }
Hi Steve,
On Tue, Aug 7, 2018 at 7:28 PM, Steven Rostedt wrote:
> On Tue, 7 Aug 2018 19:13:32 -0700
> Joel Fernandes wrote:
>> >
>> >> From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
>> >> From: "Joel Fernandes (Google)"
>> >> Date: Sun, 5 Aug 2018 20:17:41 -0700
>> >> Su
On Tue, 7 Aug 2018 19:13:32 -0700
Joel Fernandes wrote:
> On Tue, Aug 7, 2018 at 6:55 PM, Steven Rostedt wrote:
> > On Tue, 7 Aug 2018 18:17:42 -0700
> > Joel Fernandes wrote:
> >
> >> From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
> >> From: "Joel Fernandes (Google)"
On Tue, Aug 7, 2018 at 6:55 PM, Steven Rostedt wrote:
> On Tue, 7 Aug 2018 18:17:42 -0700
> Joel Fernandes wrote:
>
>> From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
>> From: "Joel Fernandes (Google)"
>> Date: Sun, 5 Aug 2018 20:17:41 -0700
>> Subject: [PATCH] tracepoint:
On Tue, 7 Aug 2018 18:17:42 -0700
Joel Fernandes wrote:
> From 6986af946ceb04fc9ddc6d5b45fc559b6807e465 Mon Sep 17 00:00:00 2001
> From: "Joel Fernandes (Google)"
> Date: Sun, 5 Aug 2018 20:17:41 -0700
> Subject: [PATCH] tracepoint: Run tracepoints even after CPU is offline
>
> Commit f37755490
On Tue, Aug 7, 2018 at 5:48 PM, Steven Rostedt wrote:
> On Tue, 07 Aug 2018 19:54:13 -0400
> Joel Fernandes wrote:
>
>
>> >OK, I hit this bug, but it's not because of the partial revert. This
>> >bug seems it needs to be another partial revert. I like you movement of
>> >the code, but I'm startin
On Tue, 07 Aug 2018 19:54:13 -0400
Joel Fernandes wrote:
> >OK, I hit this bug, but it's not because of the partial revert. This
> >bug seems it needs to be another partial revert. I like you movement of
> >the code, but I'm starting to doubt that we can use a trace event as a
> >hook for critic
On August 7, 2018 7:45:15 PM EDT, Steven Rostedt wrote:
>On Tue, 07 Aug 2018 11:24:13 -0400
>Joel Fernandes wrote:
>
>> On August 7, 2018 11:09:06 AM EDT, Steven Rostedt
> wrote:
>> >On Tue, 07 Aug 2018 10:48:05 -0400
>> >Joel Fernandes wrote:
>> >
>> >> >You mean if someone add a tracepoin
On Tue, 07 Aug 2018 11:24:13 -0400
Joel Fernandes wrote:
> On August 7, 2018 11:09:06 AM EDT, Steven Rostedt wrote:
> >On Tue, 07 Aug 2018 10:48:05 -0400
> >Joel Fernandes wrote:
> >
> >> >You mean if someone add a tracepoint callback to the irq disable
> >> >tracepoint, and did a lockdep ass
On August 7, 2018 11:09:06 AM EDT, Steven Rostedt wrote:
>On Tue, 07 Aug 2018 10:48:05 -0400
>Joel Fernandes wrote:
>
>> >You mean if someone add a tracepoint callback to the irq disable
>> >tracepoint, and did a lockdep assert to make sure interrupts are
>> >disabled?
>>
>> Yes that's what
On Tue, 07 Aug 2018 10:48:05 -0400
Joel Fernandes wrote:
> >You mean if someone add a tracepoint callback to the irq disable
> >tracepoint, and did a lockdep assert to make sure interrupts are
> >disabled?
>
> Yes that's what I meant.
That sounds like a "Doctor, it hurts me when I do this" pr
On August 7, 2018 10:34:10 AM EDT, Steven Rostedt wrote:
>On Tue, 07 Aug 2018 10:10:59 -0400
>Joel Fernandes wrote:
>
>> On August 7, 2018 9:49:54 AM EDT, Steven Rostedt
> wrote:
>> >On Tue, 7 Aug 2018 06:33:35 -0700
>> >Joel Fernandes wrote:
>> >
>> >> Thanks, also one more thing I noticed
On Tue, 07 Aug 2018 10:10:59 -0400
Joel Fernandes wrote:
> On August 7, 2018 9:49:54 AM EDT, Steven Rostedt wrote:
> >On Tue, 7 Aug 2018 06:33:35 -0700
> >Joel Fernandes wrote:
> >
> >> Thanks, also one more thing I noticed in your patch,
> >> lockdep_hardirqs_off needs to be called before al
On August 7, 2018 9:49:54 AM EDT, Steven Rostedt wrote:
>On Tue, 7 Aug 2018 06:33:35 -0700
>Joel Fernandes wrote:
>
>> Thanks, also one more thing I noticed in your patch,
>> lockdep_hardirqs_off needs to be called before all other probes but
>> you're calling it after. This is why I registere
On Tue, 7 Aug 2018 06:33:35 -0700
Joel Fernandes wrote:
> Thanks, also one more thing I noticed in your patch,
> lockdep_hardirqs_off needs to be called before all other probes but
> you're calling it after. This is why I registered it with INT_MAX:
>
> register_trace_prio_irq_disable(lockdep_ha
On Mon, Aug 6, 2018 at 6:43 PM, Steven Rostedt wrote:
> On Mon, 6 Aug 2018 17:43:19 -0700
> Joel Fernandes wrote:
>
>> On Mon, Aug 6, 2018 at 12:50 PM, Steven Rostedt wrote:
>> >
>> > With this patch applied, I'm constantly getting lockdep errors. Instead
>> > of doing a full revert of the patch
On Mon, 6 Aug 2018 17:43:19 -0700
Joel Fernandes wrote:
> On Mon, Aug 6, 2018 at 12:50 PM, Steven Rostedt wrote:
> >
> > With this patch applied, I'm constantly getting lockdep errors. Instead
> > of doing a full revert of the patch, I did this, which makes all those
> > errors go away. I may ap
On Mon, Aug 6, 2018 at 12:50 PM, Steven Rostedt wrote:
>
> With this patch applied, I'm constantly getting lockdep errors. Instead
> of doing a full revert of the patch, I did this, which makes all those
> errors go away. I may apply this for now, and we can revisit having
> lockdep use the tracep
With this patch applied, I'm constantly getting lockdep errors. Instead
of doing a full revert of the patch, I did this, which makes all those
errors go away. I may apply this for now, and we can revisit having
lockdep use the tracepoint code. But since it's currently always
enabled, I'm thinking
From: "Joel Fernandes (Google)"
This patch detaches the preemptirq tracepoints from the tracers and
keeps it separate.
Advantages:
* Lockdep and irqsoff event can now run in parallel since they no longer
have their own calls.
* This unifies the usecase of adding hooks to an irqsoff and irqson
e
43 matches
Mail list logo
