[PATCH v2 3/6] tracing: Use .flush() call to wake up readers

From: "Steven Rostedt (Google)" The .release() function does not get called until all readers of a file descriptor are finished. If a thread is blocked on reading a file descriptor in ring_buffer_wait(), and another thread closes the file descriptor, it will not wake up the other

[PATCH v2 2/6] ring-buffer: Fix resetting of shortest_full

From: "Steven Rostedt (Google)" The "shortest_full" variable is used to keep track of the waiter that is waiting for the smallest amount on the ring buffer before being woken up. When a tasks waits on the ring buffer, it passes in a "full" value that is a percentag

[PATCH v2 1/6] ring-buffer: Fix waking up ring buffer readers

From: "Steven Rostedt (Google)" A task can wait on a ring buffer for when it fills up to a specific watermark. The writer will check the minimum watermark that waiters are waiting for and if the ring buffer is past that, it will wake up all the waiters. The waiters are in a wait loop

[PATCH v2 0/6] tracing/ring-buffer: Fix wakeup of ring buffer waiters

tex_lock() after a prepare_to_wait() that changed the task's state. Convert the affected mutex over to a spinlock. Steven Rostedt (Google) (6): ring-buffer: Fix waking up ring buffer readers ring-buffer: Fix resetting of shortest_full tracing: Use .flush() call to wake

Re: [PATCH 4/6] tracing: Fix waking up tracing readers

On Fri, 08 Mar 2024 13:38:20 -0500 Steven Rostedt wrote: > +static DEFINE_MUTEX(wait_mutex); > + > +static bool wait_woken_prepare(struct trace_iterator *iter, int *wait_index) > +{ > + bool woken = false; > + > + mutex_lock(&wait_mutex); > + if (iter-&g

[PATCH 5/6] ring-buffer: Restructure ring_buffer_wait() to prepare for updates

From: "Steven Rostedt (Google)" The ring_buffer_wait() needs to be broken into three functions for proper synchronization from the context of the callers: ring_buffer_prepare_to_wait() ring_buffer_wait() ring_buffer_finish_wait() To simplify the process, pull out the logic f

[PATCH 6/6] tracing/ring-buffer: Fix wait_on_pipe() race

From: "Steven Rostedt (Google)" When the trace_pipe_raw file is closed, there should be no new readers on the file descriptor. This is mostly handled with the waking and wait_index fields of the iterator. But there's still a slight race. CPU 0

[PATCH 3/6] tracing: Use .flush() call to wake up readers

From: "Steven Rostedt (Google)" The .release() function does not get called until all readers of a file descriptor are finished. If a thread is blocked on reading a file descriptor in ring_buffer_wait(), and another thread closes the file descriptor, it will not wake up the other

[PATCH 2/6] ring-buffer: Fix resetting of shortest_full

From: "Steven Rostedt (Google)" The "shortest_full" variable is used to keep track of the waiter that is waiting for the smallest amount on the ring buffer before being woken up. When a tasks waits on the ring buffer, it passes in a "full" value that is a percentag

[PATCH 4/6] tracing: Fix waking up tracing readers

From: "Steven Rostedt (Google)" When the tracing_pipe_raw file is closed, if there are readers still blocked on it, they need to be woken up. Currently a wait_index is used. When the readers need to be woken, the index is updated and they are all woken up. But there is a race where a

[PATCH 1/6] ring-buffer: Fix waking up ring buffer readers

From: "Steven Rostedt (Google)" A task can wait on a ring buffer for when it fills up to a specific watermark. The writer will check the minimum watermark that waiters are waiting for and if the ring buffer is past that, it will wake up all the waiters. The waiters are in a wait loop

[PATCH 0/6] tracing/ring-buffer: Fix wakeup of ring buffer waiters

queue, check if its own condition has been set (in this case: iter->waking) and then sleep. Follows the same semantics as any other wait logic. Steven Rostedt (Google) (6): ring-buffer: Fix waking up ring buffer readers ring-buffer: Fix resetting of shortest_full tracin

Re: [PATCH v2] workqueue: add function in event of workqueue_activate_work

> Signed-off-by: Kassey Li > --- > Changelog: > v1: > https://lore.kernel.org/all/20240308010929.1955339-1-quic_yinga...@quicinc.com/ > v1->v2: > - do not follow checkpatch in TRACE_EVENT() macros > - add sample "workqueue_activate_work: work struct ff80413a78b

Re: [PATCH] workqueue: add function in event of workqueue_activate_work

On Fri, 8 Mar 2024 09:09:29 +0800 Kassey Li wrote: > The trace event "workqueue_activate_work" only print work struct. > However, function is the region of interest in a full sequence of work. > Current workqueue_activate_work trace event output: > > workqueue_activate_work: work struct

Re: [PATCH] ring-buffer: mark racy accesses on work->wait_index

On Wed, 6 Mar 2024 10:55:34 +0800 linke li wrote: > Mark data races to work->wait_index as benign using READ_ONCE and WRITE_ONCE. > These accesses are expected to be racy. Are we now to the point that every single access of a variable (long size or less) needs a READ_ONCE/WRITE_ONCE even with

[POC] !!! Re: [PATCH 0/8] tracing: Persistent traces across a reboot or crash

I forgot to add [POC] to the topic. All these patches are a proof of concept. -- Steve

[PATCH 8/8] ring-buffer: Validate boot range memory events

From: "Steven Rostedt (Google)" Make sure all the events in each of the sub-buffers that were mapped in a memory region are valid. This moves the code that walks the buffers for time-stamp validation out of the CONFIG_RING_BUFFER_VALIDATE_TIME_DELTAS ifdef block and is used to va

[PATCH 7/8] ring-buffer: Add test if range of boot buffer is valid

From: "Steven Rostedt (Google)" Add a test against the ring buffer memory range to see if it has valid data. The ring_buffer_meta structure is given a new field called "first_buffer" which holds the address of the first sub-buffer. This is used to both determine if the other

[PATCH 5/8] ring-buffer: Add ring_buffer_meta data

From: "Steven Rostedt (Google)" Populate the ring_buffer_meta array. It holds the pointer to the head_buffer (next to read), the commit_buffer (next to write) the size of the sub-buffers, number of sub-buffers and an array that keeps track of the order of the sub-buffers. This inform

[PATCH 6/8] ring-buffer: Add output of ring buffer meta page

From: "Steven Rostedt (Google)" Add a buffer_meta per-cpu file for the trace instance that is mapped to boot memory. This shows the current meta-data and can be used by user space tools to record off the current mappings to help reconstruct the ring buffer after a reboot. It does not

[PATCH 3/8] tracing: Create "boot_mapped" instance for memory mapped buffer

From: "Steven Rostedt (Google)" Add two global variables trace_buffer_start and trace_buffer_size. If they are both set, then a "boot_mapped" instance will be created using the memory specified by these variables as its ring buffer. The instance will exist in: /sys/kern

[PATCH 4/8] HACK: Hard code in mapped tracing buffer address

From: "Steven Rostedt (Google)" Do not submit! This is for testing purposes only. It hard codes an address that I was using to store the ring buffer range. How the memory actually gets mapped will be another project. Signed-off-by: Steven Rostedt (Google) --- arch/x86/kernel/se

[PATCH 0/8] tracing: Persistent traces across a reboot or crash

es/boot_mapped/trace and it will have the trace. I'm sure there's still some gotchas here, which is why this is currently still just a POC. Enjoy... Steven Rostedt (Google) (8): ring-buffer: Allow mapped field to be set without mapping ring-buffer: Add ring_buffer_

[PATCH 2/8] ring-buffer: Add ring_buffer_alloc_range()

From: "Steven Rostedt (Google)" In preparation to allowing the trace ring buffer to be allocated in a range of memory that is persistent across reboots, add ring_buffer_alloc_range(). It takes a contiguous range of memory and will split it up evening for the per CPU ring buffers. If t

[PATCH 1/8] ring-buffer: Allow mapped field to be set without mapping

From: "Steven Rostedt (Google)" In preparation for having the ring buffer mapped to a dedicated location, which will have the same restrictions as user space memory mapped buffers, allow it to use the "mapped" field of the ring_buffer_per_cpu structure without having the

[PATCH v2] tracing: Limit trace_marker writes to just 4K

From: "Steven Rostedt (Google)" Limit the max print event of trace_marker to just 4K string size. This must also be less than the amount that can be held by a trace_seq along with the text that is before the output (like the task name, PID, CPU, state, etc). As trace_seq is made to ha

Re: [PATCH] tracing: Have trace_marker writes be just half of TRACE_SEQ_SIZE

On Mon, 4 Mar 2024 21:48:44 -0500 Mathieu Desnoyers wrote: > On 2024-03-04 21:37, Steven Rostedt wrote: > > On Mon, 4 Mar 2024 21:35:38 -0500 > > Steven Rostedt wrote: > > > >>> And it's not for debugging, it's for validation of assumptions > >

Re: [PATCH] tracing: Have trace_marker writes be just half of TRACE_SEQ_SIZE

On Mon, 4 Mar 2024 21:35:38 -0500 Steven Rostedt wrote: > > And it's not for debugging, it's for validation of assumptions > > made about an upper bound limit defined for a compile-time > > check, so as the code evolves issues are caught early. > > validatin

Re: [PATCH] tracing: Have trace_marker writes be just half of TRACE_SEQ_SIZE

On Mon, 4 Mar 2024 21:18:13 -0500 Mathieu Desnoyers wrote: > On 2024-03-04 20:59, Steven Rostedt wrote: > > On Mon, 4 Mar 2024 20:42:39 -0500 > > Mathieu Desnoyers wrote: > > > >> #define TRACE_OUTPUT_META_DATA_MAX_LEN 80 > >> > >>

Re: [PATCH] tracing: Have trace_marker writes be just half of TRACE_SEQ_SIZE

On Mon, 4 Mar 2024 20:42:39 -0500 Mathieu Desnoyers wrote: > #define TRACE_OUTPUT_META_DATA_MAX_LEN80 > > and a runtime check in the code generating this header. > > This would avoid adding an unchecked upper limit. That would be a lot of complex code that is for debugging some

Re: [PATCH] tracing: Have trace_marker writes be just half of TRACE_SEQ_SIZE

On Mon, 4 Mar 2024 20:36:28 -0500 Mathieu Desnoyers wrote: > > <...>-999 [001] . 2296.140373: tracing_mark_write: > > hello > > ^^^ > > This is the meta data that is added to trace_seq > > If this hea

Re: [PATCH] tracing: Have trace_marker writes be just half of TRACE_SEQ_SIZE

On Mon, 4 Mar 2024 20:35:16 -0500 Steven Rostedt wrote: > > BUILD_BUG_ON(TRACING_MARK_MAX_SIZE + sizeof(meta data stuff...) > > > TRACE_SEQ_SIZE); > > That's not the meta size I'm worried about. The sizeof(meta data) is the > raw event binary data, which

Re: [PATCH] tracing: Have trace_marker writes be just half of TRACE_SEQ_SIZE

On Mon, 4 Mar 2024 20:15:57 -0500 Mathieu Desnoyers wrote: > On 2024-03-04 19:27, Steven Rostedt wrote: > > From: "Steven Rostedt (Google)" > > > > Since the size of trace_seq's buffer is the max an event can output, have > > the trace_marker be half

Re: [PATCH] tracing: Have trace_marker writes be just half of TRACE_SEQ_SIZE

On Mon, 4 Mar 2024 16:43:46 -0800 Randy Dunlap wrote: > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c > > index 8198bfc54b58..d68544aef65f 100644 > > --- a/kernel/trace/trace.c > > +++ b/kernel/trace/trace.c > > @@ -7320,6 +7320,17 @@ tracing_mark_write(struct file *filp, const char

[PATCH] tracing: Have trace_marker writes be just half of TRACE_SEQ_SIZE

From: "Steven Rostedt (Google)" Since the size of trace_seq's buffer is the max an event can output, have the trace_marker be half of the entire TRACE_SEQ_SIZE, which is 4K. That will keep writes that has meta data written from being dropped (but reported), because the total outp

Re: [PATCH] tracing: Remove precision vsnprintf() check from print event

On Mon, 4 Mar 2024 18:55:00 -0500 Steven Rostedt wrote: > On Mon, 4 Mar 2024 18:23:41 -0500 > Mathieu Desnoyers wrote: > > > It appears to currently be limited by > > > > #define TRACE_SEQ_BUFFER_SIZE (PAGE_SIZE * 2 - \ > > (sizeof(struct seq_b

[PATCH] tracing: Limit trace_seq size to just 8K and not depend on architecture PAGE_SIZE

From: "Steven Rostedt (Google)" The trace_seq buffer is used to print out entire events. It's typically set to PAGE_SIZE * 2 as there's some events that can be quite large. As a side effect, writes to trace_marker is limited by both the size of the trace_seq buffer as well

Re: [PATCH] tracing: Remove precision vsnprintf() check from print event

On Mon, 4 Mar 2024 18:23:41 -0500 Mathieu Desnoyers wrote: > It appears to currently be limited by > > #define TRACE_SEQ_BUFFER_SIZE (PAGE_SIZE * 2 - \ > (sizeof(struct seq_buf) + sizeof(size_t) + sizeof(int))) > > checked within tracing_mark_write(). Yeah, I can hard code this to 8

[PATCH] tracing: Remove precision vsnprintf() check from print event

From: "Steven Rostedt (Google)" This reverts 60be76eeabb3d ("tracing: Add size check when printing trace_marker output"). The only reason the precision check was added was because of a bug that miscalculated the write size of the string into the ring buffer and it trunc

Re: [PATCH RFC ftrace] Chose RCU Tasks based on TASKS_RCU rather than PREEMPTION

On Fri, 1 Mar 2024 12:25:10 -0800 "Paul E. McKenney" wrote: > > That would work for me. If there are no objections, I will make this > > change. > > But I did check the latency of synchronize_rcu_tasks_rude() (about 100ms) > and synchronize_rcu() (about 20ms). This is on a 80-hardware-thread

Re: [PATCH] ring-buffer: use READ_ONCE() to read cpu_buffer->commit_page in concurrent environment

On Fri, 1 Mar 2024 11:37:54 -0500 Mathieu Desnoyers wrote: > On 2024-03-01 10:49, Steven Rostedt wrote: > > On Fri, 1 Mar 2024 13:37:18 +0800 > > linke wrote: > > > >>> So basically you are worried about read-tearing? > >>> > >>>

Re: [PATCH] ring-buffer: use READ_ONCE() to read cpu_buffer->commit_page in concurrent environment

On Fri, 1 Mar 2024 13:37:18 +0800 linke wrote: > > So basically you are worried about read-tearing? > > > > That wasn't mentioned in the change log. > > Yes. Sorry for making this confused, I am not very familiar with this and > still learning. No problem. We all have to learn this anyway.

Re: [PATCH] ring-buffer: use READ_ONCE() to read cpu_buffer->commit_page in concurrent environment

On Thu, 29 Feb 2024 20:32:26 +0800 linke wrote: > Hi Steven, sorry for the late reply. > > > > > Now the reason for the above READ_ONCE() is because the variables *are* > > going to be used again. We do *not* want the compiler to play any games > > with that. > > > > I don't think it is bec

Re: [PATCH RFC ftrace] Chose RCU Tasks based on TASKS_RCU rather than PREEMPTION

just might > happen within a trampoline. > > Therefore, update ftrace_shutdown() to invoke synchronize_rcu_tasks() > based on CONFIG_TASKS_RCU instead of CONFIG_PREEMPTION. > > Only build tested. > > Signed-off-by: Paul E. McKenney > Cc: Steven Rostedt > Cc: Ma

[PATCH] tracepoints: Use WARN() and not WARN_ON() for warnings

From: "Steven Rostedt (Google)" There are two WARN_ON*() warnings in tracepoint.h that deal with RCU usage. But when they trigger, especially from using a TRACE_EVENT() macro, the information is not very helpful and is confusing: [ cut here ] WARNING: CPU: 0

Re: [PATCH v2] mm: add alloc_contig_migrate_range allocation statistics

nsigned long end, > + unsigned long nr_migrated, > + unsigned long nr_reclaimed, > + unsigned long nr_mapped, > + int migratetype), Well, you didn't need to change the order of the parameters. Anyway, from a tracing point of vi

[PATCH] tracing: Prevent trace_marker being bigger than unsigned short

From: "Steven Rostedt (Google)" The trace_marker write goes into the ring buffer. A test was added to write a string as big as the sub-buffer of the ring buffer to see if it would work. A sub-buffer is typically PAGE_SIZE in length. On PowerPC architecture, the ftrace selftest for tr

Re: [PATCH] net/ipv4: add tracepoint for icmp_send

On Tue, 27 Feb 2024 10:50:36 +0800 (CST) wrote: > include/trace/events/icmp.h | 57 > + > net/ipv4/icmp.c | 4 > 2 files changed, 61 insertions(+) > create mode 100644 include/trace/events/icmp.h > > diff --git a/include/trace/even

Re: [PATCH] ring-buffer: use READ_ONCE() to read cpu_buffer->commit_page in concurrent environment

On Sun, 25 Feb 2024 15:03:02 -0500 Steven Rostedt wrote: > *But* looking at this deeper, the commit_page may need a READ_ONCE() > but not for the reason you suggested. > > commit_page = cpu_buffer->commit_page; > commit_ts = commit_page->page->time_sta

Re: [PATCH] tracefs: remove SLAB_MEM_SPREAD flag usage

On Sat, 24 Feb 2024 13:52:06 + chengming.z...@linux.dev wrote: > From: Chengming Zhou > > The SLAB_MEM_SPREAD flag is already a no-op as of 6.8-rc1, remove > its usage so we can delete it from slab. No functional change. > > Signed-off-by: Chengming Zhou Queued. Thanks! -- Steve > ---

Re: [PATCH] mm: add alloc_contig_migrate_range allocation statistics

On Mon, 26 Feb 2024 12:06:29 -0500 Steven Rostedt wrote: > On Mon, 26 Feb 2024 10:00:15 + > Richard Chang wrote: > > > alloc_contig_migrate_range has every information to be able to > > understand big contiguous allocation latency. For example, how many > > p

Re: [PATCH v2] tracing: Add warning if string in __assign_str() does not match __string()

On Mon, 26 Feb 2024 09:33:28 +0900 Masami Hiramatsu (Google) wrote: > On Fri, 23 Feb 2024 16:13:56 -0500 > Steven Rostedt wrote: > > > From: "Steven Rostedt (Google)" > > > > In preparation to remove the second parameter of __assign_str(), make sure >

Re: [PATCH] mm: add alloc_contig_migrate_range allocation statistics

On Mon, 26 Feb 2024 10:00:15 + Richard Chang wrote: > alloc_contig_migrate_range has every information to be able to > understand big contiguous allocation latency. For example, how many > pages are migrated, how many times they were needed to unmap from > page tables. > > This patch adds th

Re: [PATCH] ring-buffer: use READ_ONCE() to read cpu_buffer->commit_page in concurrent environment

On Sun, 25 Feb 2024 11:05:06 +0800 linke li wrote: > In function ring_buffer_iter_empty(), cpu_buffer->commit_page and > curr_commit_page->page->time_stamp is read using READ_ONCE() in > line 4354, 4355 > > 4354curr_commit_page = READ_ONCE(cpu_buffer->commit_page); > 4355curr_commit_ts

[PATCH] tracing: Remove second parameter to __assign_rel_str()

From: "Steven Rostedt (Google)" The second parameter of __assign_rel_str() is no longer used. It can be removed. Note, the only real users of rel_string is user events. This code is just in the sample code for testing purposes. This makes __assign_rel_str() different than __assign

[PATCH v2] tracing: Add warning if string in __assign_str() does not match __string()

From: "Steven Rostedt (Google)" In preparation to remove the second parameter of __assign_str(), make sure it is really a duplicate of __string() by adding a WARN_ON_ONCE(). Signed-off-by: Steven Rostedt (Google) --- Changes since v1: https://lore.kernel.org/linux-tr

[PATCH] tracing: Add warning if string in __assign_str() does not match __string()

From: "Steven Rostedt (Google)" In preparation to remove the second parameter of __assign_str(), make sure it is really a duplicate of __string() by adding a WARN_ON_ONCE(). Signed-off-by: Steven Rostedt (Google) --- include/trace/stages/stage6_event_callback.h | 1 + 1 file

[PATCH] tracing: Add __string_len() example

From: "Steven Rostedt (Google)" There's no example code that uses __string_len(), and since the sample code is used for testing the event logic, add a use case. Signed-off-by: Steven Rostedt (Google) --- samples/trace_events/trace-events-sample.h | 7 +-- 1 file change

[PATCH v2] tracing: Remove __assign_str_len()

From: "Steven Rostedt (Google)" Now that __assign_str() gets the length from the __string() (and __string_len()) macros, there's no reason to have a separate __assign_str_len() macro as __assign_str() can get the length of the string needed. Also remove __assign_rel_str() alt

[PATCH] tracing: Remove __assign_str_len()

From: "Steven Rostedt (Google)" Now that __assign_str() gets the length from the __string() (and __string_len()) macros, there's no reason to have a separate __assign_str_len() macro as __assign_str() can get the length of the string needed. Signed-off-by: Steven Rostedt (Google

[PATCH 1/2] tracing: Fix snapshot counter going between two tracers that use it

From: "Steven Rostedt (Google)" Running the ftrace selftests caused the ring buffer mapping test to fail. Investigating, I found that the snapshot counter would be incremented every time a tracer that uses the snapshot is enabled even if the snapshot was used by the previous tracer

[PATCH 0/2] tracing: Fix snapshot accounting

The ring buffer mapping test failed after running the ftrace tests. This was due to some mismatched snapshot accounting that left the snapshot counter enabled when it was not, which prevents the ring buffer from being mapped. Steven Rostedt (Google) (2): tracing: Fix snapshot counter

[PATCH 2/2] tracing: Decrement the snapshot if the snapshot trigger fails to register

From: "Steven Rostedt (Google)" Running the ftrace selftests caused the ring buffer mapping test to fail. Investigating, I found that the snapshot counter would be incremented every time a snapshot trigger was added, even if that snapshot trigger failed. # cd /sys/kernel/traci

Re: [PATCH v4 2/4] tracing/user_events: Introduce multi-format events

On Thu, 22 Feb 2024 00:18:05 + Beau Belgrave wrote: > Currently user_events supports 1 event with the same name and must have > the exact same format when referenced by multiple programs. This opens > an opportunity for malicous or poorly thought through programs to malicious? ;-) -- Stev

Re: [PATCH v4 1/4] tracing/user_events: Prepare find/delete for same name events

On Thu, 22 Feb 2024 00:18:04 + Beau Belgrave wrote: > The current code for finding and deleting events assumes that there will > never be cases when user_events are registered with the same name, but > different formats. Scenarios exist where programs want to use the same > name but have diff

[PATCH v2 4/4] tracing: Use EVENT_NULL_STR macro instead of open coding "(null)"

From: "Steven Rostedt (Google)" The TRACE_EVENT macros has some dependency if a __string() field is NULL, where it will save "(null)" as the string. This string is also used by __assign_str(). It's better to create a single macro instead of having something that

[PATCH v2 3/4] tracing: Use ? : shortcut in trace macros

From: "Steven Rostedt (Google)" Instead of having: #define __assign_str(dst, src)\ memcpy(__get_str(dst), __data_offsets.dst##_ptr_ ? \ __data_offsets.dst##_ptr

[PATCH v2 2/4] tracing: Do not calculate strlen() twice for __string() fields

From: "Steven Rostedt (Google)" The TRACE_EVENT() macro handles dynamic strings by having: TP_PROTO(struct some_struct *s), TP_ARGS(s), TP_STRUCT__entry( __string(my_string, s->string) ), TP_fast_assign( __assign_str(my_string, s->string); ) TP_printk

[PATCH v2 1/4] tracing: Rework __assign_str() and __string() to not duplicate getting the string

From: "Steven Rostedt (Google)" The TRACE_EVENT() macro handles dynamic strings by having: TP_PROTO(struct some_struct *s), TP_ARGS(s), TP_STRUCT__entry( __string(my_string, s->string) ), TP_fast_assign( __assign_str(my_string, s->string); ) TP_printk

[PATCH v2 0/4] tracing: Optimize __string()/__assign_str() processing

tring must be consistent between __string() and __assign_str(). Steven Rostedt (Google) (4): tracing: Rework __assign_str() and __string() to not duplicate getting the string tracing: Do not calculate strlen() twice for __string() fields tracing: Use ? : shortcut in trace macros

[PATCH 2/2] tracing: Do not calculate strlen() twice for __string() fields

From: "Steven Rostedt (Google)" The TRACE_EVENT() macro handles dynamic strings by having: TP_PROTO(struct some_struct *s), TP_ARGS(s), TP_STRUCT__entry( __string(my_string, s->string) ), TP_fast_assign( __assign_str(my_string, s->string); ) TP_printk

[PATCH 0/2] tracing: Optimize __string()/__assign_str() processing

and length of the string fields. Instead of finding the string twice, just save it off in another field in that helper structure, and have __assign_str() use that instead. Steven Rostedt (Google) (2): tracing: Rework __assign_str() and __string() to not duplicate getting the string

[PATCH 1/2] tracing: Rework __assign_str() and __string() to not duplicate getting the string

From: "Steven Rostedt (Google)" The TRACE_EVENT() macro handles dynamic strings by having: TP_PROTO(struct some_struct *s), TP_ARGS(s), TP_STRUCT__entry( __string(my_string, s->string) ), TP_fast_assign( __assign_str(my_string, s->string); ) TP_printk

Re: [PATCH] NFSD: Fix nfsd_clid_class use of __string_len() macro

On Thu, 22 Feb 2024 13:25:34 -0500 Chuck Lever wrote: > Do you want me to take this through the nfsd tree, or would you like > an Ack from me so you can handle it as part of your clean up? Just > in case: > > Acked-by: Chuck Lever > As my patches depend on this, I can take it with your ack.

[PATCH] NFSD: Fix nfsd_clid_class use of __string_len() macro

From: "Steven Rostedt (Google)" I'm working on restructuring the __string* macros so that it doesn't need to recalculate the string twice. That is, it will save it off when processing __string() and the __assign_str() will not need to do the work again as it curren

Re: [PATCH v1] PM: runtime: add tracepoint for runtime_status changes

On Wed, 21 Feb 2024 09:57:03 -0800 Vilas Bhat wrote: > > You could do what everyone else does: > > > > #define RPM_STATUS_STRINGS \ > > EM( RPM_INVALID, "RPM_INVALID" )\ > > EM( RPM_ACTIVE, "RPM_ACTIVE" ) \ > > EM( RPM_RESUMING, "RPM_R

Re: [PATCH v1] PM: runtime: add tracepoint for runtime_status changes

On Wed, 21 Feb 2024 16:41:10 + Vilas Bhat wrote: > diff --git a/include/trace/events/rpm.h b/include/trace/events/rpm.h > index 3c716214dab1..f1dc4e95dbce 100644 > --- a/include/trace/events/rpm.h > +++ b/include/trace/events/rpm.h > @@ -101,6 +101,42 @@ TRACE_EVENT(rpm_return_int, >

Re: [PATCH v3 2/4] tracing/user_events: Introduce multi-format events

On Wed, 14 Feb 2024 17:50:44 + Beau Belgrave wrote: > Currently user_events supports 1 event with the same name and must have > the exact same format when referenced by multiple programs. This opens > an opportunity for malicous or poorly thought through programs to > create events that other

Re: [PATCH v3 1/4] tracing/user_events: Prepare find/delete for same name events

On Wed, 14 Feb 2024 17:50:43 + Beau Belgrave wrote: So the patches look good, but since I gave you some updates, I'm now going to go though "nits". Like grammar and such ;-) > The current code for finding and deleting events assumes that there will > never be cases when user_events are regis

Re: [PATCH v3 2/4] tracing/user_events: Introduce multi-format events

On Wed, 14 Feb 2024 17:50:44 + Beau Belgrave wrote: > +static char *user_event_group_system_multi_name(void) > +{ > + char *system_name; > + int len = sizeof(USER_EVENTS_MULTI_SYSTEM) + 1; FYI, the sizeof() will include the "\0" so no need for "+ 1", but I don't think this matters as

Re: [PATCH] sched: Add trace events for Proxy Execution (PE)

On Fri, 2 Feb 2024 08:33:38 + Metin Kaya wrote: > Add sched_[start, finish]_task_selection trace events to measure the > latency of PE patches in task selection. > > Moreover, introduce trace events for interesting events in PE: > 1. sched_pe_enqueue_sleeping_task: a task gets enqueued on w

Re: [PATCH] bus: mhi: host: Change the trace string for the userspace tools mapping

add trace point strings for the user space tools to map strings > > properly. > > > > Signed-off-by: Krishna chaitanya chundru > > Reported-by: Steven Rostedt Suggested-by: may be more accurate? -- Steve > Reviewed-by: Manivannan Sadhasivam

Re: [PATCH -next v6 0/2] Make memory reclamation measurable

7 kswapd0 super_cache_scan.cfi_jt 0 > > 2247 8524 1024 > > 7 kswapd0 super_cache_scan.cfi_jt 23670 > >00 > > > > For this, add the new tracer to shrink_active_list/shrin

Re: [PATCH v3] ring-buffer: Simplify reservation with try_cmpxchg() loop

On Tue, 20 Feb 2024 10:40:23 -0500 Steven Rostedt wrote: > > Try resetting the info->add_timestamp flags to add_ts_default on goto again > > within __rb_reserve_next(). > > > > I was looking at that too, but I don't know how it will make a difference. > &

Re: [PATCH v3] ring-buffer: Simplify reservation with try_cmpxchg() loop

On Tue, 20 Feb 2024 09:50:13 -0500 Mathieu Desnoyers wrote: > On 2024-02-20 09:19, Steven Rostedt wrote: > > On Mon, 19 Feb 2024 18:20:32 -0500 > > Steven Rostedt wrote: > > > >> Instead of using local_add_return() to reserve the ring buffer data, > >

[PATCH] ring-buffer: Do not let subbuf be bigger than write mask

From: "Steven Rostedt (Google)" The data on the subbuffer is measured by a write variable that also contains status flags. The counter is just 20 bits in length. If the subbuffer is bigger than then counter, it will fail. Make sure that the subbuffer can not be set to greater than t

Re: [PATCH v3] ring-buffer: Simplify reservation with try_cmpxchg() loop

On Mon, 19 Feb 2024 18:20:32 -0500 Steven Rostedt wrote: > Instead of using local_add_return() to reserve the ring buffer data, > Mathieu Desnoyers suggested using local_cmpxchg(). This would simplify the > reservation with the time keeping code. > > Although, it does not get ri

[PATCH v4 3/3] tracing: Move saved_cmdline code into trace_sched_switch.c

From: "Steven Rostedt (Google)" The code that handles saved_cmdlines is split between the trace.c file and the trace_sched_switch.c. There's some history to this. The trace_sched_switch.c was originally created to handle the sched_switch tracer that was deprecated due to sched_swi

[PATCH v4 1/3] tracing: Have saved_cmdlines arrays all in one allocation

From: "Steven Rostedt (Google)" The saved_cmdlines have three arrays for mapping PIDs to COMMs: - map_pid_to_cmdline[] - map_cmdline_to_pid[] - saved_cmdlines The map_pid_to_cmdline[] is PID_MAX_DEFAULT in size and holds the index into the other arrays. The map_cmdline_to_pid[] is

[PATCH v4 2/3] tracing: Move open coded processing of tgid_map into helper function

From: "Steven Rostedt (Google)" In preparation of moving the saved_cmdlines logic out of trace.c and into trace_sched_switch.c, replace the open coded manipulation of tgid_map in set_tracer_flag() into a helper function trace_alloc_tgid_map() so that it can be easily

[PATCH v4 0/3] tracing: Changes to saved_cmdlines

ace-kernel/20240216210047.584712...@goodmis.org/ - The map_cmdline_to_pid field was moved into the pages allocated of the structure and that replaced the kmalloc. But that field still had kfree() called on it in the freeing of the structure which caused a memory corruption. Steven Rostedt (

[PATCH v3] ring-buffer: Simplify reservation with try_cmpxchg() loop

From: "Steven Rostedt (Google)" Instead of using local_add_return() to reserve the ring buffer data, Mathieu Desnoyers suggested using local_cmpxchg(). This would simplify the reservation with the time keeping code. Although, it does not get rid of the double time stamps (before

Re: [PATCH v2] ring-buffer: Simplify reservation with try_cmpxchg() loop

On Mon, 19 Feb 2024 17:30:03 -0500 Steven Rostedt wrote: > - /*C*/ write = local_add_return(info->length, &tail_page->write); > + /*C*/ if (!local_try_cmpxchg(&tail_page->write, &w, w + > info->length)) { > + if (info

[PATCH v2] ring-buffer: Simplify reservation with try_cmpxchg() loop

From: "Steven Rostedt (Google)" Instead of using local_add_return() to reserve the ring buffer data, Mathieu Desnoyers suggested using local_cmpxchg(). This would simplify the reservation with the time keeping code. Although, it does not get rid of the double time stamps (before

Re: [PATCH v17 3/6] tracing: Add snapshot refcount

On Mon, 19 Feb 2024 13:17:54 -0500 Steven Rostedt wrote: > On Tue, 13 Feb 2024 11:49:42 + > Vincent Donnefort wrote: > > > @@ -9678,7 +9739,9 @@ trace_array_create_systems(const char *name, const > > char *systems) > > raw_spin_lock_init(&tr->start

Re: [PATCH v17 3/6] tracing: Add snapshot refcount

On Tue, 13 Feb 2024 11:49:42 + Vincent Donnefort wrote: > @@ -9678,7 +9739,9 @@ trace_array_create_systems(const char *name, const char > *systems) > raw_spin_lock_init(&tr->start_lock); > > tr->max_lock = (arch_spinlock_t)__ARCH_SPIN_LOCK_UNLOCKED; > - > +#ifdef CONFIG_TRCER_M

Re: [PATCH v7 22/36] function_graph: Add a new entry handler with parent_ip and ftrace_regs

On Wed, 7 Feb 2024 00:11:34 +0900 "Masami Hiramatsu (Google)" wrote: > From: Masami Hiramatsu (Google) > > Add a new entry handler to fgraph_ops as 'entryregfunc' which takes > parent_ip and ftrace_regs. Note that the 'entryfunc' and 'entryregfunc' > are mutual exclusive. You can set only one

[PATCH v3 3/3] tracing: Move saved_cmdline code into trace_sched_switch.c

From: "Steven Rostedt (Google)" The code that handles saved_cmdlines is split between the trace.c file and the trace_sched_switch.c. There's some history to this. The trace_sched_switch.c was originally created to handle the sched_switch tracer that was deprecated due to sched_swi

[PATCH v3 2/3] tracing: Move open coded processing of tgid_map into helper function

From: "Steven Rostedt (Google)" In preparation of moving the saved_cmdlines logic out of trace.c and into trace_sched_switch.c, replace the open coded manipulation of tgid_map in set_tracer_flag() into a helper function trace_alloc_tgid_map() so that it can be easily

[PATCH v3 1/3] tracing: Have saved_cmdlines arrays all in one allocation

From: "Steven Rostedt (Google)" The saved_cmdlines have three arrays for mapping PIDs to COMMs: - map_pid_to_cmdline[] - map_cmdline_to_pid[] - saved_cmdlines The map_pid_to_cmdline[] is PID_MAX_DEFAULT in size and holds the index into the other arrays. The map_cmdline_to_pid[] is

<    1   2   3   4   5   6   7   8   9   10   >