From: "Paul E. McKenney" <paulmck@kernel.org>
To: Daniel Bristot de Oliveira <bristot@kernel.org>
Cc: Nicolas Saenz Julienne <nsaenzju@redhat.com>,
rostedt@goodmis.org, mingo@redhat.com,
linux-kernel@vger.kernel.org, mtosatti@redhat.com
Subject: Re: [PATCH] tracing/osnoise: Force quiescent states while tracing
Date: Tue, 1 Mar 2022 10:58:23 -0800 [thread overview]
Message-ID: <20220301185823.GS4285@paulmck-ThinkPad-P17-Gen-1> (raw)
In-Reply-To: <c3cf7c0c-27fe-4dfa-4249-a7e1747237a5@kernel.org>
On Tue, Mar 01, 2022 at 07:44:38PM +0100, Daniel Bristot de Oliveira wrote:
> On 3/1/22 19:05, Paul E. McKenney wrote:
> >> I see, as long as it costs < 1 us, I am ok. If it gets > 1us in a reasonably
> >> fast machine, we start see HW noise where it does not exist, and that would
> >> reduce the resolution of osnoise. AFAICS, it is not causing that problem, but we
> >> need to make it as lightweight as possible.
> > In the common case, it is atomically incrementing a local per-CPU counter
> > and doing a store. This should be quite cheap.
> >
> > The uncommon case is when the osnoise process was preempted or otherwise
> > interfered with during a recent RCU read-side critical section and
> > preemption was disabled around that critical section's outermost
> > rcu_read_unlock(). This can be quite expensive. But I would expect
> > you to just not do this. ;-)
>
> Getting the expensive call after a preemption is not a problem, it is a side
> effect of the most costly preemption.
>
> It this case, we should "ping rcu" before reading the time to account the
> overhead for the previous preemption which caused it.
>
> like (using the current code as example):
>
> ------------------------- %< -------------------------------
> static u64
> set_int_safe_time(struct osnoise_variables *osn_var, u64 *time)
> {
> u64 int_counter;
>
> do {
> int_counter = local_read(&osn_var->int_counter);
>
> ------------> HERE <-------------------------------------
>
> /* synchronize with interrupts */
> barrier();
>
> *time = time_get();
>
> /* synchronize with interrupts */
> barrier();
> } while (int_counter != local_read(&osn_var->int_counter));
>
> return int_counter;
> }
> ------------------------- >% -------------------------------
>
> In this way anything that happens before this *time is accounted before it is
> get. If anything happens while this loop is running, it will run again, so it is
> safe to point to the previous case.
>
> We would have to make a copy of this function, and only use the copy for the
> run_osnoise() case. A good name would be something in the lines of
> set_int_safe_time_rcu().
>
> (Unless the expensive is < than 1us.)
The outermost rcu_read_unlock() could involve a call into the scheduler
to do an RCU priority deboost, which I would imagine could be a bit
expensive. But I would expect you to configure the test in such a way
that there was no need for RCU priority boosting. For example, by making
sure that the osnoise process's RCU readers were never preempted.
Just out of curiosity, why is this running in the kernel rather than in
userspace? To focus only on kernel-centric noise sources? Or are there
people implementing real-time applications within the kernel?
Thanx, Paul
next prev parent reply other threads:[~2022-03-01 18:58 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
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 [this message]
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=20220301185823.GS4285@paulmck-ThinkPad-P17-Gen-1 \
--to=paulmck@kernel.org \
--cc=bristot@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mtosatti@redhat.com \
--cc=nsaenzju@redhat.com \
--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®