mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Daniel Bristot de Oliveira <bristot@kernel.org>
To: Nicolas Saenz Julienne <nsaenzju@redhat.com>,
	rostedt@goodmis.org, paulmck@kernel.org
Cc: mingo@redhat.com, linux-kernel@vger.kernel.org, mtosatti@redhat.com
Subject: Re: [PATCH] tracing/osnoise: Force quiescent states while tracing
Date: Mon, 28 Feb 2022 21:00:26 +0100	[thread overview]
Message-ID: <137d3573-051f-5374-70d6-cc99b44d00da@kernel.org> (raw)
In-Reply-To: <20220228141423.259691-1-nsaenzju@redhat.com>

On 2/28/22 15:14, Nicolas Saenz Julienne wrote:
> At the moment running osnoise on an isolated CPU and a PREEMPT_RCU
> kernel might have the side effect of extending grace periods too much.
> This will eventually entice RCU to schedule a task on the isolated CPU
> to end the overly extended grace period, adding unwarranted noise to the
> CPU being traced in the process.
> 
> So, check if we're the only ones running on this isolated CPU and that
> we're on a PREEMPT_RCU setup. If so, let's force quiescent states in
> between measurements.
> 
> Non-PREEMPT_RCU setups don't need to worry about this as osnoise main
> loop's cond_resched() will go though a quiescent state for them.
> 
> Note that this same exact problem is what extended quiescent states were
> created for. But adapting them to this specific use-case isn't trivial
> as it'll imply reworking entry/exit and dynticks/context tracking code.
> 
> Signed-off-by: Nicolas Saenz Julienne <nsaenzju@redhat.com>
> ---
>  kernel/trace/trace_osnoise.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/kernel/trace/trace_osnoise.c b/kernel/trace/trace_osnoise.c
> index 870a08da5b48..4928358f6e88 100644
> --- a/kernel/trace/trace_osnoise.c
> +++ b/kernel/trace/trace_osnoise.c
> @@ -21,7 +21,9 @@
>  #include <linux/uaccess.h>
>  #include <linux/cpumask.h>
>  #include <linux/delay.h>
> +#include <linux/tick.h>
>  #include <linux/sched/clock.h>
> +#include <linux/sched/isolation.h>
>  #include <uapi/linux/sched/types.h>
>  #include <linux/sched.h>
>  #include "trace.h"
> @@ -1295,6 +1297,7 @@ static int run_osnoise(void)
>  	struct osnoise_sample s;
>  	unsigned int threshold;
>  	u64 runtime, stop_in;
> +	unsigned long flags;
>  	u64 sum_noise = 0;
>  	int hw_count = 0;
>  	int ret = -1;
> @@ -1386,6 +1389,22 @@ static int run_osnoise(void)
>  					osnoise_stop_tracing();
>  		}
>  
> +		/*
> +		 * Check if we're the only ones running on this nohz_full CPU
> +		 * and that we're on a PREEMPT_RCU setup. If so, let's fake a
> +		 * QS since there is no way for RCU to know we're not making
> +		 * use of it.
> +		 *
> +		 * Otherwise it'll be done through cond_resched().
> +		 */
> +		if (IS_ENABLED(CONFIG_PREEMPT_RCU) &&
> +		    !housekeeping_cpu(raw_smp_processor_id(), HK_FLAG_MISC) &&

Does this restrict to only isolcpus cpus? what if this CPU was isolated via
other methods?

> +		    tick_nohz_tick_stopped()) {
> +			local_irq_save(flags);

This code is always with interrupts enabled, so local_irq_disable()/enable()
should be enough (and faster).

> +			rcu_momentary_dyntick_idle();
> +			local_irq_restore(flags);
> +		}

Question, if we set this once, we could avoid setting it on every loop unless we
have a preemption from another thread, right?

>  		/*
>  		 * For the non-preemptive kernel config: let threads runs, if
>  		 * they so wish.

/me keeps playing with this patch.

-- Daniel

  parent reply	other threads:[~2022-02-28 20:25 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-28 14:14 Nicolas Saenz Julienne
2022-02-28 15:45 ` Steven Rostedt
2022-03-01 10:59   ` Nicolas Saenz Julienne
2022-03-01 17:30     ` Daniel Bristot de Oliveira
2022-02-28 20:00 ` Daniel Bristot de Oliveira [this message]
2022-03-01 10:52   ` Nicolas Saenz Julienne
2022-03-01 17:55     ` Daniel Bristot de Oliveira
2022-03-01 18:05       ` Paul E. McKenney
2022-03-01 18:44         ` Daniel Bristot de Oliveira
2022-03-01 18:58           ` Paul E. McKenney
2022-03-01 19:29             ` Daniel Bristot de Oliveira
2022-03-01 19:46               ` Paul E. McKenney
2022-03-01 19:53                 ` Daniel Bristot de Oliveira
2022-02-28 22:11 ` Paul E. McKenney
2022-03-01 10:00   ` Nicolas Saenz Julienne
2022-03-01 17:44     ` Daniel Bristot de Oliveira
2022-03-01 17:56     ` Paul E. McKenney
2022-03-02 10:46       ` Nicolas Saenz Julienne
2022-03-04 14:28 ` Daniel Bristot de Oliveira
2022-03-04 14:36   ` Nicolas Saenz Julienne
2022-03-04 14:39     ` Daniel Bristot de Oliveira
2022-03-04 14:51     ` Daniel Bristot de Oliveira
2022-03-04 15:28       ` Nicolas Saenz Julienne
2022-03-04 15:37         ` Daniel Bristot de Oliveira
2022-03-04 15:55           ` Nicolas Saenz Julienne
2022-03-04 16:26             ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=137d3573-051f-5374-70d6-cc99b44d00da@kernel.org \
    --to=bristot@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=nsaenzju@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®