Re: [PATCH 2/3] x86/xen: move paravirt lazy code

On Wed, 13 Sep 2023 13:38:27 +0200 Juergen Gross wrote: > diff --git a/include/trace/events/xen.h b/include/trace/events/xen.h > index 44a3f565264d..0577f0cdd231 100644 > --- a/include/trace/events/xen.h > +++ b/include/trace/events/xen.h > @@ -6,26 +6,26 @@ > #define _TRACE_XEN_H > >

Re: [PATCH 01/20] x86: move prepare_ftrace_return prototype to header

07f9595 100644 > --- a/arch/x86/include/asm/ftrace.h > +++ b/arch/x86/include/asm/ftrace.h Acked-by: Steven Rostedt (Google) -- Steve

Re: [RFC PATCH 00/30] Code tagging framework and applications

On Wed, 7 Sep 2022 09:04:28 -0400 Kent Overstreet wrote: > On Wed, Sep 07, 2022 at 01:00:09PM +0200, Michal Hocko wrote: > > Hmm, it seems that further discussion doesn't really make much sense > > here. I know how to use my time better. > > Just a thought, but I generally find it more

Re: [RFC PATCH 00/30] Code tagging framework and applications

On Mon, 5 Sep 2022 16:42:29 -0400 Kent Overstreet wrote: > > Haven't tried that yet but will do. Thanks for the reference code! > > Is it really worth the effort of benchmarking tracing API overhead here? > > The main cost of a tracing based approach is going to to be the data structure >

Re: [RFC PATCH 00/30] Code tagging framework and applications

On Mon, 5 Sep 2022 11:44:55 -0700 Nadav Amit wrote: > I would note that I have a solution in the making (which pretty much works) > for this matter, and does not require any kernel changes. It produces a > call stack that leads to the code that lead to syscall failure. > > The way it works is

Re: [RFC PATCH 00/30] Code tagging framework and applications

On Sun, 4 Sep 2022 18:32:58 -0700 Suren Baghdasaryan wrote: > Page allocations (overheads are compared to get_free_pages() duration): > 6.8% Codetag counter manipulations (__lazy_percpu_counter_add + > __alloc_tag_add) > 8.8% lookup_page_ext > 1237% call stack capture > 139% tracepoint with

Re: [RFC PATCH 27/30] Code tagging based latency tracking

On Thu, 1 Sep 2022 21:35:32 -0400 Kent Overstreet wrote: > On Thu, Sep 01, 2022 at 08:23:11PM -0400, Steven Rostedt wrote: > > If ftrace, perf, bpf can't do what you want, take a harder look to see if > > you can modify them to do so. > > Maybe we can use this exchang

Re: [RFC PATCH 27/30] Code tagging based latency tracking

On Thu, 1 Sep 2022 18:55:15 -0400 Kent Overstreet wrote: > On Thu, Sep 01, 2022 at 06:34:30PM -0400, Steven Rostedt wrote: > > On Thu, 1 Sep 2022 17:54:38 -0400 > > Kent Overstreet wrote: > > > > > > So this looks like it's gotten better si

Re: [RFC PATCH 27/30] Code tagging based latency tracking

On Thu, 1 Sep 2022 17:54:38 -0400 Kent Overstreet wrote: > > So this looks like it's gotten better since I last looked, but it's still not > there yet. > > Part of the problem is that the tracepoints themselves are in the wrong place: > your end event is when a task is woken up, but that means

Re: [RFC PATCH 27/30] Code tagging based latency tracking

On Thu, 1 Sep 2022 17:38:44 -0400 Steven Rostedt wrote: > # echo 'hist:keys=comm,prio,delta.buckets=10:sort=delta' > > /sys/kernel/tracing/events/synthetic/wakeup_lat/trigger The above could almost be done with sqlhist (but I haven't implemented "buckets=10" yet because t

Re: [RFC PATCH 27/30] Code tagging based latency tracking

On Tue, 30 Aug 2022 14:49:16 -0700 Suren Baghdasaryan wrote: > From: Kent Overstreet > > This adds the ability to easily instrument code for measuring latency. > To use, add the following to calls to your code, at the start and end of > the event you wish to measure: > >

Re: [RFC PATCH 03/30] Lazy percpu counters

On Thu, 1 Sep 2022 10:32:19 -0400 Kent Overstreet wrote: > On Thu, Sep 01, 2022 at 08:51:31AM +0200, Peter Zijlstra wrote: > > On Tue, Aug 30, 2022 at 02:48:52PM -0700, Suren Baghdasaryan wrote: > > > +static void lazy_percpu_counter_switch_to_pcpu(struct > > > raw_lazy_percpu_counter *c) > >

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 23/30] printk: kmsg_dump: Introduce helper to inform number of dumpers

On Wed, 27 Apr 2022 19:49:17 -0300 "Guilherme G. Piccoli" wrote: > Currently we don't have a way to check if there are dumpers set, > except counting the list members maybe. This patch introduces a very > simple helper to provide this information, by just keeping track of >

Re: [PATCH 18/30] notifier: Show function names on notifier routines if DEBUG_NOTIFIERS is set

On Thu, 28 Apr 2022 09:01:13 +0800 Xiaoming Ni wrote: > > +#ifdef CONFIG_DEBUG_NOTIFIERS > > + { > > + char sym_name[KSYM_NAME_LEN]; > > + > > + pr_info("notifiers: registered %s()\n", > > + notifier_name(n, sym_name)); > > + } > > Duplicate Code. >

Re: [PATCH 04/30] firmware: google: Convert regular spinlock into trylock on panic path

On Tue, 10 May 2022 13:38:39 +0200 Petr Mladek wrote: > As already mentioned in the other reply, panic() sometimes stops > the other CPUs using NMI, for example, see kdump_nmi_shootdown_cpus(). > > Another situation is when the CPU using the lock ends in some > infinite loop because something

Re: [PATCH 17/30] tracing: Improve panic/die notifiers

On Fri, 29 Apr 2022 10:46:35 -0300 "Guilherme G. Piccoli" wrote: > Thanks Sergei and Steven, good idea! I thought about the switch change > you propose, but I confess I got a bit confused by the "fallthrough" > keyword - do I need to use it? No. The fallthrough keyword is only needed when

Re: [PATCH 17/30] tracing: Improve panic/die notifiers

Why not: > > case DIE_OOPS: > case PANIC_NOTIFIER: > do_dump = 1; > break; Agreed. Other than that. Acked-by: Steven Rostedt (Google) -- Steve

Re: [PATCH v0 00/42] notifiers: Return an error when callback is already registered

On Mon, 8 Nov 2021 15:35:50 +0100 Borislav Petkov wrote: > On Mon, Nov 08, 2021 at 03:24:39PM +0100, Borislav Petkov wrote: > > I guess I can add another indirection to notifier_chain_register() and > > avoid touching all the call sites. > > IOW, something like this below. > > This way I

Re: [PATCH 1/4] x86/xen/entry: Rename xenpv_exc_nmi to noist_exc_nmi

On Fri, 30 Apr 2021 09:15:51 +0200 Paolo Bonzini wrote: > > Nit, but in change logs, please avoid stating "next patch" as searching git > > history (via git blame or whatever) there is no such thing as "next patch". > > > > Interesting, I use next patch(es) relatively often, though you're

Re: [PATCH 1/4] x86/xen/entry: Rename xenpv_exc_nmi to noist_exc_nmi

On Tue, 27 Apr 2021 07:09:46 +0800 Lai Jiangshan wrote: > From: Lai Jiangshan > > There is no any functionality change intended. Just rename it and > move it to arch/x86/kernel/nmi.c so that we can resue it later in > next patch for early NMI and kvm. Nit, but in change logs, please avoid

Re: A KernelShark plugin for Xen traces analysis

On Thu, 15 Apr 2021 02:50:53 +0200 Dario Faggioli wrote: > On Wed, 2021-04-14 at 15:07 -0400, Steven Rostedt wrote: > > On Wed, 14 Apr 2021 19:11:19 +0100 > > Andrew Cooper wrote: > > > > > Where the plugin (ought to) live depends heavily on whether we > &g

Re: A KernelShark plugin for Xen traces analysis

On Thu, 15 Apr 2021 00:11:32 +0200 Dario Faggioli wrote: > Yes, basically, we can say that a Xen system has "its own trace-cmd". > It's called `xentrace`, you run it from Dom0 and you get a (binary) > file which contains a bunch of events. > > Not that differently from a trace-cmd's

Re: A KernelShark plugin for Xen traces analysis

On Wed, 14 Apr 2021 19:11:19 +0100 Andrew Cooper wrote: > Where the plugin (ought to) live depends heavily on whether we consider > the trace format a stable ABI or not. Agreed. Like the VMware plugin to handle ESX traces. It's internal and not published as the API is not stable. But if it

Re: A KernelShark plugin for Xen traces analysis

On Wed, 14 Apr 2021 11:07:33 +0100 Andrew Cooper wrote: > On 13/04/2021 16:46, Steven Rostedt wrote: > > Hi Giuseppe, > > > > On Tue, 13 Apr 2021 16:28:36 +0200 > > Giuseppe Eletto wrote: > > > >> Hello, > >> I want to share with you a new

Re: A KernelShark plugin for Xen traces analysis

Hi Giuseppe, On Tue, 13 Apr 2021 16:28:36 +0200 Giuseppe Eletto wrote: > Hello, > I want to share with you a new plugin developed by me, under the > supervision of Dario Faggioli, which allows the new version of KernelShark > (the v2-beta) to open and view the Xen traces created using the

Re: [Xen-devel] [PATCH v3 21/27] x86/ftrace: Adapt function tracing for PIE support

On Thu, 24 May 2018 13:40:24 +0200 Petr Mladek wrote: > On Wed 2018-05-23 12:54:15, Thomas Garnier wrote: > > When using -fPIE/PIC with function tracing, the compiler generates a > > call through the GOT (call *__fentry__@GOTPCREL). This instruction > > takes 6 bytes instead of

[Xen-devel] [GIT PULL] tracing/x86/xen: Remove zero data size trace events trace_xen_mmu_flush_tlb{_all}

the latest trace-v4.17-rc4-2 tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git trace-v4.17-rc4-2 Tag SHA1: 580faa7b1b80b1332683dc869732a4db8a506b9c Head SHA1: 45dd9b0666a162f8e4be76096716670cf1741f0e Steven Rostedt (VMware) (1): tracing/x86/xen