Re: [RFC PATCH v2 0/8] Generic IPI sending tracepoint

ing point. For the tracing portions: Reviewed-by: Steven Rostedt (Google) -- Steve ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [RFC PATCH 0/5] Generic IPI sending tracepoint

On Tue, 11 Oct 2022 17:40:26 +0100 Valentin Schneider wrote: > > You could keep the tracepoint as a mask, and then make it pretty, like > > cpus=3-5,8 > > in user-space. For example with a trace-cmd/perf loadable plugin, > > libtracefs helper. > > > > That's a nice idea, the one downside I

Re: [RFC PATCH 0/5] Generic IPI sending tracepoint

On Tue, 11 Oct 2022 17:17:04 +0100 Valentin Schneider wrote: > tep_get_field_val() just yields an unsigned long long of value 0x200018, > which AFAICT is just the [length, offset] thing associated with dynamic > arrays. Not really usable, and I don't see anything exported in the lib to > extract

Re: [RFC PATCH 0/5] Generic IPI sending tracepoint

On Fri, 7 Oct 2022 17:01:33 -0300 Marcelo Tosatti wrote: > > As for the targeted CPUs, the existing tracepoint does export them, albeit > > in > > cpumask form, which is quite inconvenient from a tooling perspective. For > > instance, as far as I'm aware, it's not possible to do event filtering

Re: [RFC PATCH 4/5] irq_work: Trace calls to arch_irq_work_raise()

On Fri, 7 Oct 2022 16:45:32 +0100 Valentin Schneider wrote: > } > > +static inline void irq_work_raise(void) > +{ > + if (arch_irq_work_has_interrupt()) > + trace_ipi_send_cpu(_RET_IP_, smp_processor_id()); To save on the branch, let's make the above: if

Re: [PATCH v2 33/44] ftrace: WARN on rcuidle

Nit, the subject should have "tracing:" an not "ftrace:" as the former encompasses the tracing infrastructure and the latter is for the function hook part of that. On Mon, 19 Sep 2022 12:00:12 +0200 Peter Zijlstra wrote: > CONFIG_GENERIC_ENTRY disallows any and all tracing when RCU isn't >

Re: [PATCH 24/36] printk: Remove trace_.*_rcuidle() usage

On Thu, 9 Jun 2022 15:02:20 +0200 Petr Mladek wrote: > > I'm somewhat curious whether we can actually remove that trace event. > > Good question. > > Well, I think that it might be useful. It allows to see trace and > printk messages together. Yes people still use it. I was just asked about

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Thu, 24 Sep 2020 19:55:10 +0200 Thomas Gleixner wrote: > On Thu, Sep 24 2020 at 08:32, Steven Rostedt wrote: > > On Thu, 24 Sep 2020 08:57:52 +0200 > > Thomas Gleixner wrote: > > > >> > Now as for migration disabled nesting, at least now we would have >

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Thu, 24 Sep 2020 14:42:41 +0200 Peter Zijlstra wrote: > On Thu, Sep 24, 2020 at 08:32:41AM -0400, Steven Rostedt wrote: > > Anyway, instead of blocking. What about having a counter of number of > > migrate disabled tasks per cpu, and when taking a migrate_disable(), a

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Thu, 24 Sep 2020 08:57:52 +0200 Thomas Gleixner wrote: > > Now as for migration disabled nesting, at least now we would have > > groupings of this, and perhaps the theorists can handle that. I mean, > > how is this much different that having a bunch of tasks blocked on a > > mutex with the

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Wed, 23 Sep 2020 22:55:54 +0200 Thomas Gleixner wrote: > > Perhaps make migrate_disable() an anonymous local_lock()? > > > > This should lower the SHC in theory, if you can't have stacked migrate > > disables on the same CPU. > > I'm pretty sure this ends up in locking hell pretty fast and

Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

On Wed, 23 Sep 2020 10:40:32 +0200 pet...@infradead.org wrote: > However, with migrate_disable() we can have each task preempted in a > migrate_disable() region, worse we can stack them all on the _same_ CPU > (super ridiculous odds, sure). And then we end up only able to run one > task, with the

Re: [RFC] ARC: initial ftrace support

On Thu, 2 Apr 2020 01:17:01 + Vineet Gupta wrote: > +CC Claudiu > > On 3/27/20 10:10 AM, Steven Rostedt wrote: > > On Fri, 27 Mar 2020 18:53:55 +0300 > > Eugeniy Paltsev wrote: > > Maybe add a comment that gcc does the heavy lifting: I have following in

Re: [RFC] ARC: initial ftrace support

On Fri, 27 Mar 2020 18:53:55 +0300 Eugeniy Paltsev wrote: > + > +noinline void _mcount(unsigned long parent_ip) > +{ > + unsigned long ip = (unsigned long)__builtin_return_address(0); > + > + if (unlikely(ftrace_trace_function != ftrace_stub)) > + ftrace_trace_function(ip -

Re: [PATCH 00/50] Add log level to show_stack()

On Wed, 13 Nov 2019 09:47:22 +0100 Petr Mladek wrote: > At the moment, I am in favor of this patchset. It is huge and > needed a lot of manual work. But the result is straightforward and > easy to understand. I'm in favor of this patchset too. If there's other areas that need to adjust the

Re: [PATCH 00/50] Add log level to show_stack()

On Wed, 6 Nov 2019 23:25:13 + Russell King - ARM Linux admin wrote: > On Wed, Nov 06, 2019 at 09:34:40PM +0100, Peter Zijlstra wrote: > > I suppose I'm surprised there are backtraces that are not important. > > Either badness happened and it needs printing, or the user asked for it > > and

Re: [PATCH 00/50] Add log level to show_stack()

On Wed, 6 Nov 2019 21:34:40 +0100 Peter Zijlstra wrote: > I suppose I'm surprised there are backtraces that are not important. > Either badness happened and it needs printing, or the user asked for it > and it needs printing. Unfortunately that is the case. As my tests will fail if a backtrace

Re: [PATCH 00/50] Add log level to show_stack()

On Tue, 12 Nov 2019 11:17:47 +0900 Sergey Senozhatsky wrote: > void show_stack(struct task_struct *task, unsigned long *sp, int log_level) > { > printk_emergency_enter(log_level); > __show_stack(task, sp); > printk_emergency_exit(); > } > // - - - - - - - - - - - - - - - - - -

Re: [PATCH 00/50] Add log level to show_stack()

On Tue, 12 Nov 2019 13:44:47 +0900 Sergey Senozhatsky wrote: > > > I do recall that we talked about per-CPU printk state bit which would > > > start/end "just print it" section. We probably can extend it to "just > > > log_store" type of functionality. Doesn't look like a very bad idea. > > >

Re: [PATCH 5/6 v3] syscalls: Remove start and number from syscall_get_arguments() args

On Thu, 4 Apr 2019 21:17:58 +0300 "Dmitry V. Levin" wrote: > There are several places listed below where I'd prefer to see more readable > equivalents, but feel free to leave it to respective arch maintainers. I was going to do similar changes, but figured I'd do just that (let the arch

[PATCH 6/6 v3] syscalls: Remove start and number from syscall_set_arguments() args

From: "Steven Rostedt (VMware)" After removing the start and count arguments of syscall_get_arguments() it seems reasonable to remove them from syscall_set_arguments(). Note, as of today, there are no users of syscall_set_arguments(). But we are told that there will be soon. B

[PATCH 5/6 v3] syscalls: Remove start and number from syscall_get_arguments() args

From: "Steven Rostedt (Red Hat)" At Linux Plumbers, Andy Lutomirski approached me and pointed out that the function call syscall_get_arguments() implemented in x86 was horribly written and not optimized for the standard case of passing in 0 and 6 for the starting index and the number

[RFC][PATCH 3/4 v2] syscalls: Remove start and number from syscall_get_arguments() args

From: "Steven Rostedt (Red Hat)" At Linux Plumbers, Andy Lutomirski approached me and pointed out that the function call syscall_get_arguments() implemented in x86 was horribly written and not optimized for the standard case of passing in 0 and 6 for the starting index and the number

[RFC][PATCH 4/4 v2] syscalls: Remove start and number from syscall_set_arguments() args

From: "Steven Rostedt (VMware)" After removing the start and count arguments of syscall_get_arguments() it seems reasonable to remove them from syscall_set_arguments(). Note, as of today, there are no users of syscall_set_arguments(). But we are told that there will be soon. B

Re: [PATCH] OF: move extern declarations of entry pointers inside ifdef

On Fri, 25 Aug 2017 15:20:12 + Eugeniy Paltsev <eugeniy.palt...@synopsys.com> wrote: > On Fri, 2017-08-25 at 11:12 -0400, Steven Rostedt wrote: > > On Fri, 25 Aug 2017 18:00:26 +0300 > > Eugeniy Paltsev <eugeniy.palt...@synopsys.com> wrote: > > > >

Re: [PATCH] OF: move extern declarations of entry pointers inside ifdef

d > of "CONFIG_OF" ifdef in their usage places. > > Suggested-by: Steven Rostedt <rost...@goodmis.org> Thanks! -- Steve > > Signed-off-by: Eugeniy Paltsev <eugeniy.palt...@synopsys.com> > --- ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] console: don't select first registered console if stdout-path used

On Fri, 25 Aug 2017 16:14:51 +0300 Eugeniy Paltsev wrote: > In the current implementation we take the first console that > registers if we didn't select one. > > But if we specify console via "stdout-path" property in device tree > we don't want first console that