Excerpts from Steven Rostedt's message of June 30, 2020 8:16 am:
> On Thu, 25 Jun 2020 15:34:03 +1000
> Nicholas Piggin wrote:
>
>> Batch these up so we disable all the per-cpu buffers first, then
>> synchronize_rcu() once, then reset each of the buffers. This brings
>> the time down to about 0.5
On Thu, 25 Jun 2020 15:34:03 +1000
Nicholas Piggin wrote:
> Batch these up so we disable all the per-cpu buffers first, then
> synchronize_rcu() once, then reset each of the buffers. This brings
> the time down to about 0.5s.
After applying this patch, running tools/testing/selftests/ftracetest
On Mon, 29 Jun 2020 08:35:11 -0700
"Paul E. McKenney" wrote:
> Looks plausible from an RCU viewpoint:
>
> Acked-by: Paul E. McKenney
Thanks Nicholas, Anton and Paul,
I'll pull this in and start testing it.
-- Steve
On Thu, Jun 25, 2020 at 03:34:03PM +1000, Nicholas Piggin wrote:
> On a 144 thread system, `perf ftrace` takes about 20 seconds to start
> up, due to calling synchronize_rcu() for each CPU.
>
> cat /proc/108560/stack
> 0xc0003e7eb336f470
> __switch_to+0x2e0/0x480
> __wait_rcu_gp+0x20
Hi Nick,
> On a 144 thread system, `perf ftrace` takes about 20 seconds to start
> up, due to calling synchronize_rcu() for each CPU.
>
> cat /proc/108560/stack
> 0xc0003e7eb336f470
> __switch_to+0x2e0/0x480
> __wait_rcu_gp+0x20c/0x220
> synchronize_rcu+0x9c/0xc0
> ring_buff
On a 144 thread system, `perf ftrace` takes about 20 seconds to start
up, due to calling synchronize_rcu() for each CPU.
cat /proc/108560/stack
0xc0003e7eb336f470
__switch_to+0x2e0/0x480
__wait_rcu_gp+0x20c/0x220
synchronize_rcu+0x9c/0xc0
ring_buffer_reset_cpu+0x88/0x2e0
6 matches
Mail list logo