On Wed, Apr 18, 2018 at 2:02 AM Masami Hiramatsu
wrote:
> On Mon, 16 Apr 2018 21:07:47 -0700
> Joel Fernandes wrote:
> > With TRACE_IRQFLAGS, we call trace_ API too many times. We don't need
> > to if local_irq_restore or local_irq_save didn't actually do anything.
> >
> > This gives around a 4
- On Apr 26, 2018, at 11:03 AM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
> - On Apr 25, 2018, at 6:51 PM, rostedt rost...@goodmis.org wrote:
>
>> On Wed, 25 Apr 2018 17:40:56 -0400 (EDT)
>> Mathieu Desnoyers wrote:
>>
>>> One problem with your approach is that you can ha
On Thu, Apr 26, 2018 at 11:13:16AM -0400, Mathieu Desnoyers wrote:
> - On Apr 25, 2018, at 7:13 PM, Joel Fernandes joe...@google.com wrote:
>
> > Hi Mathieu,
> >
> > On Wed, Apr 25, 2018 at 2:40 PM, Mathieu Desnoyers
> > wrote:
> >> - On Apr 25, 2018, at 5:27 PM, Joel Fernandes joe...@go
On Thu, Apr 26, 2018 at 8:13 AM, Mathieu Desnoyers
wrote:
[...]
>>> Regarding the name, I'm OK with having something along the lines of
>>> trace_*event*_blocking or such. Please don't use "srcu" or other naming
>>> that is explicitly tied to the underlying mechanism used internally
>>> however: w
- On Apr 25, 2018, at 7:13 PM, Joel Fernandes joe...@google.com wrote:
> Hi Mathieu,
>
> On Wed, Apr 25, 2018 at 2:40 PM, Mathieu Desnoyers
> wrote:
>> - On Apr 25, 2018, at 5:27 PM, Joel Fernandes joe...@google.com wrote:
>>
>>> On Tue, Apr 24, 2018 at 9:20 PM, Paul E. McKenney
>>> wro
- On Apr 25, 2018, at 6:51 PM, rostedt rost...@goodmis.org wrote:
> On Wed, 25 Apr 2018 17:40:56 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> One problem with your approach is that you can have multiple callers
>> for the same tracepoint name, where some could be non-preemptible and
>> others
On Sun, Apr 22, 2018 at 8:19 PM, Paul E. McKenney
wrote:
> On Sun, Apr 22, 2018 at 06:14:18PM -0700, Joel Fernandes wrote:
[...]
>> I narrowed the performance hit down to the call to
>> rcu_irq_enter_irqson() and rcu_irq_exit_irqson() in __DO_TRACE.
>> Commenting these 2 functions brings the perf
Hi Mathieu,
On Wed, Apr 25, 2018 at 2:40 PM, Mathieu Desnoyers
wrote:
> - On Apr 25, 2018, at 5:27 PM, Joel Fernandes joe...@google.com wrote:
>
>> On Tue, Apr 24, 2018 at 9:20 PM, Paul E. McKenney
>> wrote:
>> [..]
>
> Sounds good, thanks.
>
> Also I found the reason for
On Wed, 25 Apr 2018 17:40:56 -0400 (EDT)
Mathieu Desnoyers wrote:
> One problem with your approach is that you can have multiple callers
> for the same tracepoint name, where some could be non-preemptible and
> others blocking. Also, there is then no clear way for the callback
> registration API
- On Apr 25, 2018, at 5:27 PM, Joel Fernandes joe...@google.com wrote:
> On Tue, Apr 24, 2018 at 9:20 PM, Paul E. McKenney
> wrote:
> [..]
>>> >
>>> > Sounds good, thanks.
>>> >
>>> > Also I found the reason for my boot issue. It was because the
>>> > init_srcu_struct in the prototype was bei
On Wed, Apr 25, 2018 at 02:27:08PM -0700, Joel Fernandes wrote:
> On Tue, Apr 24, 2018 at 9:20 PM, Paul E. McKenney
> wrote:
> [..]
> >> >
> >> > Sounds good, thanks.
> >> >
> >> > Also I found the reason for my boot issue. It was because the
> >> > init_srcu_struct in the prototype was being done
On Tue, Apr 24, 2018 at 9:20 PM, Paul E. McKenney
wrote:
[..]
>> >
>> > Sounds good, thanks.
>> >
>> > Also I found the reason for my boot issue. It was because the
>> > init_srcu_struct in the prototype was being done in an initcall.
>> > Instead if I do it in start_kernel before the tracepoint i
On Tue, Apr 24, 2018 at 05:10:49PM -0700, Paul E. McKenney wrote:
> On Tue, Apr 24, 2018 at 04:46:54PM -0700, Joel Fernandes wrote:
> >
> >
> > On 04/24/2018 04:21 PM, Mathieu Desnoyers wrote:
> > >- On Apr 24, 2018, at 2:59 PM, Joel Fernandes joe...@google.com wrote:
> > >>On Tue, Apr 24, 20
On Tue, Apr 24, 2018 at 04:46:54PM -0700, Joel Fernandes wrote:
>
>
> On 04/24/2018 04:21 PM, Mathieu Desnoyers wrote:
> >- On Apr 24, 2018, at 2:59 PM, Joel Fernandes joe...@google.com wrote:
> >>On Tue, Apr 24, 2018 at 11:26 AM, Paul E. McKenney
> >> wrote:
> >>>On Tue, Apr 24, 2018 at 11:2
On 04/24/2018 04:21 PM, Mathieu Desnoyers wrote:
- On Apr 24, 2018, at 2:59 PM, Joel Fernandes joe...@google.com wrote:
On Tue, Apr 24, 2018 at 11:26 AM, Paul E. McKenney
wrote:
On Tue, Apr 24, 2018 at 11:23:02AM -0700, Paul E. McKenney wrote:
On Tue, Apr 24, 2018 at 10:26:58AM -0700, P
- On Apr 24, 2018, at 2:59 PM, Joel Fernandes joe...@google.com wrote:
> Hi Paul,
>
> On Tue, Apr 24, 2018 at 11:26 AM, Paul E. McKenney
> wrote:
>> On Tue, Apr 24, 2018 at 11:23:02AM -0700, Paul E. McKenney wrote:
>>> On Tue, Apr 24, 2018 at 10:26:58AM -0700, Paul E. McKenney wrote:
>>> > O
On Tue, Apr 24, 2018 at 12:09 PM, Paul E. McKenney
wrote:
> On Tue, Apr 24, 2018 at 11:59:32AM -0700, Joel Fernandes wrote:
>> Hi Paul,
>>
>> On Tue, Apr 24, 2018 at 11:26 AM, Paul E. McKenney
>> wrote:
>> > On Tue, Apr 24, 2018 at 11:23:02AM -0700, Paul E. McKenney wrote:
>> >> On Tue, Apr 24, 2
On Tue, Apr 24, 2018 at 11:59:32AM -0700, Joel Fernandes wrote:
> Hi Paul,
>
> On Tue, Apr 24, 2018 at 11:26 AM, Paul E. McKenney
> wrote:
> > On Tue, Apr 24, 2018 at 11:23:02AM -0700, Paul E. McKenney wrote:
> >> On Tue, Apr 24, 2018 at 10:26:58AM -0700, Paul E. McKenney wrote:
> >> > On Tue, Ap
On Tue, Apr 24, 2018 at 11:59 AM, Joel Fernandes wrote:
[...]
>>> > > By the way is there any limitation on using SRCU too early during
>>> > > boot? I backported Mathieu's srcu tracepoint patches but the kernel
>>> > > hangs pretty early in the boot. I register lockdep probes in
>>> > > start_ker
Hi Paul,
On Tue, Apr 24, 2018 at 11:26 AM, Paul E. McKenney
wrote:
> On Tue, Apr 24, 2018 at 11:23:02AM -0700, Paul E. McKenney wrote:
>> On Tue, Apr 24, 2018 at 10:26:58AM -0700, Paul E. McKenney wrote:
>> > On Tue, Apr 24, 2018 at 09:01:34AM -0700, Joel Fernandes wrote:
>> > > On Tue, Apr 24, 2
On Tue, Apr 24, 2018 at 11:23:02AM -0700, Paul E. McKenney wrote:
> On Tue, Apr 24, 2018 at 10:26:58AM -0700, Paul E. McKenney wrote:
> > On Tue, Apr 24, 2018 at 09:01:34AM -0700, Joel Fernandes wrote:
> > > On Tue, Apr 24, 2018 at 8:56 AM, Paul E. McKenney
> > > wrote:
> > > > On Mon, Apr 23, 201
On Tue, Apr 24, 2018 at 10:26:58AM -0700, Paul E. McKenney wrote:
> On Tue, Apr 24, 2018 at 09:01:34AM -0700, Joel Fernandes wrote:
> > On Tue, Apr 24, 2018 at 8:56 AM, Paul E. McKenney
> > wrote:
> > > On Mon, Apr 23, 2018 at 05:22:44PM -0400, Steven Rostedt wrote:
> > >> On Mon, 23 Apr 2018 13:1
On Tue, Apr 24, 2018 at 09:01:34AM -0700, Joel Fernandes wrote:
> On Tue, Apr 24, 2018 at 8:56 AM, Paul E. McKenney
> wrote:
> > On Mon, Apr 23, 2018 at 05:22:44PM -0400, Steven Rostedt wrote:
> >> On Mon, 23 Apr 2018 13:12:21 -0400 (EDT)
> >> Mathieu Desnoyers wrote:
> >>
> >>
> >> > I'm incline
On Tue, Apr 24, 2018 at 8:56 AM, Paul E. McKenney
wrote:
> On Mon, Apr 23, 2018 at 05:22:44PM -0400, Steven Rostedt wrote:
>> On Mon, 23 Apr 2018 13:12:21 -0400 (EDT)
>> Mathieu Desnoyers wrote:
>>
>>
>> > I'm inclined to explicitly declare the tracepoints with their given
>> > synchronization me
On Mon, Apr 23, 2018 at 05:22:44PM -0400, Steven Rostedt wrote:
> On Mon, 23 Apr 2018 13:12:21 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>
> > I'm inclined to explicitly declare the tracepoints with their given
> > synchronization method. Tracepoint probe callback functions for currently
> > exis
On Mon, 23 Apr 2018 13:12:21 -0400 (EDT)
Mathieu Desnoyers wrote:
> I'm inclined to explicitly declare the tracepoints with their given
> synchronization method. Tracepoint probe callback functions for currently
> existing tracepoints expect to have preemption disabled when invoked.
> This assu
Hi Mathieu,
On Mon, Apr 23, 2018 at 10:12 AM, Mathieu Desnoyers
wrote:
> - On Apr 23, 2018, at 12:18 PM, rostedt rost...@goodmis.org wrote:
>
>> On Mon, 23 Apr 2018 10:59:43 -0400 (EDT)
>> Mathieu Desnoyers wrote:
>>
>>> The main open question here is whether we want one SRCU grace period
>>
- On Apr 23, 2018, at 12:18 PM, rostedt rost...@goodmis.org wrote:
> On Mon, 23 Apr 2018 10:59:43 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> The main open question here is whether we want one SRCU grace period
>> domain per SRCU tracepoint definition, or just one SRCU domain for all
>> SRCU
On Mon, 23 Apr 2018 10:59:43 -0400 (EDT)
Mathieu Desnoyers wrote:
> The main open question here is whether we want one SRCU grace period
> domain per SRCU tracepoint definition, or just one SRCU domain for all
> SRCU tracepoints would be fine.
>
> I'm not sure what we would gain by having the ex
Hi,
On Mon, Apr 23, 2018 at 7:53 AM, Steven Rostedt wrote:
> On Mon, 23 Apr 2018 10:31:28 -0400 (EDT)
> Mathieu Desnoyers wrote:
[..]
>> I would be tempted to proceed carefully and introduce a new kind of SRCU
>> tracepoint rather than changing all existing ones from sched-rcu to SRCU
>> though.
On Mon, Apr 23, 2018 at 10:59:43AM -0400, Mathieu Desnoyers wrote:
> - On Apr 23, 2018, at 10:53 AM, rostedt rost...@goodmis.org wrote:
>
> > On Mon, 23 Apr 2018 10:31:28 -0400 (EDT)
> > Mathieu Desnoyers wrote:
> >
> >> I've been wanting to introduce an alternative tracepoint instrumentatio
- On Apr 23, 2018, at 10:53 AM, rostedt rost...@goodmis.org wrote:
> On Mon, 23 Apr 2018 10:31:28 -0400 (EDT)
> Mathieu Desnoyers wrote:
>
>> I've been wanting to introduce an alternative tracepoint instrumentation
>> "flavor" for e.g. system call entry/exit which rely on SRCU rather than
>>
On Mon, 23 Apr 2018 10:31:28 -0400 (EDT)
Mathieu Desnoyers wrote:
> I've been wanting to introduce an alternative tracepoint instrumentation
> "flavor" for e.g. system call entry/exit which rely on SRCU rather than
> sched-rcu (preempt-off). This would allow taking faults within the
> instrument
- On Apr 22, 2018, at 11:19 PM, Paul E. McKenney paul...@linux.vnet.ibm.com
wrote:
> On Sun, Apr 22, 2018 at 06:14:18PM -0700, Joel Fernandes wrote:
>> On Fri, Apr 20, 2018 at 12:07 AM, Joel Fernandes wrote:
>> > Hi,
>> >
>> > Thanks Matsami and Namhyung for the suggestions!
>> >
>> > On Wed
On Sun, Apr 22, 2018 at 06:14:18PM -0700, Joel Fernandes wrote:
> On Fri, Apr 20, 2018 at 12:07 AM, Joel Fernandes wrote:
> > Hi,
> >
> > Thanks Matsami and Namhyung for the suggestions!
> >
> > On Wed, Apr 18, 2018 at 10:43 PM, Namhyung Kim wrote:
> >> On Wed, Apr 18, 2018 at 06:02:50PM +0900, M
On Fri, Apr 20, 2018 at 12:07 AM, Joel Fernandes wrote:
> Hi,
>
> Thanks Matsami and Namhyung for the suggestions!
>
> On Wed, Apr 18, 2018 at 10:43 PM, Namhyung Kim wrote:
>> On Wed, Apr 18, 2018 at 06:02:50PM +0900, Masami Hiramatsu wrote:
>>> On Mon, 16 Apr 2018 21:07:47 -0700
>>> Joel Fernand
Hi,
Thanks Matsami and Namhyung for the suggestions!
On Wed, Apr 18, 2018 at 10:43 PM, Namhyung Kim wrote:
> On Wed, Apr 18, 2018 at 06:02:50PM +0900, Masami Hiramatsu wrote:
>> On Mon, 16 Apr 2018 21:07:47 -0700
>> Joel Fernandes wrote:
>>
>> > With TRACE_IRQFLAGS, we call trace_ API too many
On Wed, Apr 18, 2018 at 06:02:50PM +0900, Masami Hiramatsu wrote:
> On Mon, 16 Apr 2018 21:07:47 -0700
> Joel Fernandes wrote:
>
> > With TRACE_IRQFLAGS, we call trace_ API too many times. We don't need
> > to if local_irq_restore or local_irq_save didn't actually do anything.
> >
> > This gives
On Mon, 16 Apr 2018 21:07:47 -0700
Joel Fernandes wrote:
> With TRACE_IRQFLAGS, we call trace_ API too many times. We don't need
> to if local_irq_restore or local_irq_save didn't actually do anything.
>
> This gives around a 4% improvement in performance when doing the
> following command: "tim
With TRACE_IRQFLAGS, we call trace_ API too many times. We don't need
to if local_irq_restore or local_irq_save didn't actually do anything.
This gives around a 4% improvement in performance when doing the
following command: "time find / > /dev/null"
Also its best to avoid these calls where possi
40 matches
Mail list logo