From: Frederic Weisbecker <fweisbec@gmail.com>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Juergen Gross <jgross@suse.com>,
"ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Peter Zijlstra <peterz@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Chris Metcalf <cmetcalf@ezchip.com>,
Jan Beulich <JBeulich@suse.com>, Christoph Lameter <cl@linux.com>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: [Ksummit-discuss] [BELATED CORE TOPIC] context tracking / nohz / RCU state
Date: Thu, 13 Aug 2015 15:03:04 +0200 [thread overview]
Message-ID: <20150813130303.GB29958@lerouge> (raw)
In-Reply-To: <20150812160342.GV3895@linux.vnet.ibm.com>
On Wed, Aug 12, 2015 at 09:03:42AM -0700, Paul E. McKenney wrote:
> On Wed, Aug 12, 2015 at 04:27:34PM +0200, Frederic Weisbecker wrote:
> > On Tue, Aug 11, 2015 at 08:42:58PM +0200, Luis R. Rodriguez wrote:
> > > On Tue, Aug 11, 2015 at 10:49:36AM -0700, Andy Lutomirski wrote:
> > > > This is a bit late, but here goes anyway.
> > > >
> > > > Having played with the x86 context tracking hooks for awhile, I think
> > > > it would be nice if core code that needs to be aware of CPU context
> > > > (kernel, user, idle, guest, etc) could come up with single,
> > > > comprehensible, easily validated set of hooks that arch code is
> > > > supposed to call.
> > > >
> > > > Currently we have:
> > > >
> > > > - RCU hooks, which come in a wide variety to notify about IRQs, NMIs, etc.
> > > >
> > > > - Context tracking hooks. Only used by some arches. Calling these
> > > > calls the RCU hooks for you in most cases. They have weird
> > > > interactions with interrupts and they're slow.
> > > >
> > > > - vtime. Beats the heck out of me.
> > > >
> > > > - Whatever deferred things Christoph keeps reminding us about.
> > > >
> > > > Honestly, I don't fully understand what all these hooks are supposed
> > > > to do, nor do I care all that much. From my perspective, the code
> > > > code should be able to do whatever it wants and rely on appropriate
> > > > notifications from arch code. It would be great if we could come up
> > > > with something straightforward that covers everything. For example:
> > > >
> > > > user_mode_to_kernel_mode()
> > > > kernel_mode_to_user_mode()
> > > > kernel_mode_to_guest_mode()
> > > > in_a_periodic_tick()
> > > > starting_nmi()
> > > > ending_nmi()
> > > > may_i_turn_off_ticks_right_now()
> > > > or, better yet:
> > > > i_am_turning_off_ticks_right_now_and_register_your_own_darned_hrtimer_if_thats_a_problem()
> > > >
> > > > Some arches may need:
> > > >
> > > > i_am_lame_and_forgot_my_previous_context()
> > >
> > > Can all this information be generalized with some basic core hooks
> > > or could some of this contextual informatioin typically vary depending
> > > on the sequence we are in ? It sounds like its the later and that's
> > > the issue ?
> >
> > That's what we do with context tracking. It tracks the context (user/kernel)
> > and stores these informations. And indeed the contextual informations can vary
> > depending for example if an exception triggered in userspace or kernelspace.
>
> Another question of interest is "Can things be arranged so that RCU uses
> the context-tracking information directly in place of rcu_dynticks?"
> In theory, the answer is clearly "yes", but the reason that RCU's
> accounting is heavyweight is the need to get precise state readout on
> other CPUs. So it is quite possible that making RCU directly use the
> context-tracking information will make that tracking slower and more
> complex, so that the overall effect will be zero net improvement.
Yeah, that's partly what I meant by "it's possible, but we might not be proud of
the result".
> But it does seem worth a look.
Sure.
next prev parent reply other threads:[~2015-08-13 13:03 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-11 17:49 Andy Lutomirski
2015-08-11 18:33 ` Paul E. McKenney
2015-08-11 19:07 ` Andy Lutomirski
2015-08-11 21:47 ` Paul E. McKenney
2015-08-11 21:52 ` Andy Lutomirski
2015-08-12 0:51 ` Paul E. McKenney
2015-08-12 1:16 ` Andy Lutomirski
2015-08-12 13:38 ` Paul E. McKenney
2015-08-12 14:52 ` Frederic Weisbecker
2015-08-12 14:38 ` Frederic Weisbecker
2015-08-12 15:59 ` Paul E. McKenney
2015-08-11 18:42 ` Luis R. Rodriguez
2015-08-11 21:50 ` Paul E. McKenney
2015-08-12 20:17 ` Luis R. Rodriguez
2015-08-12 14:27 ` Frederic Weisbecker
2015-08-12 16:03 ` Paul E. McKenney
2015-08-13 1:29 ` Lai Jiangshan
2015-08-13 13:07 ` Frederic Weisbecker
2015-08-13 13:03 ` Frederic Weisbecker [this message]
2015-08-11 19:31 ` josh
2015-08-11 21:32 ` Kevin Hilman
2015-08-12 3:56 ` Lai Jiangshan
2015-08-12 14:20 ` Frederic Weisbecker
2015-10-12 18:40 ` Theodore Ts'o
2015-10-12 19:55 ` Thomas Gleixner
2015-10-12 20:40 ` Paul E. McKenney
2015-10-16 17:02 ` Frederic Weisbecker
2015-10-17 19:45 ` Theodore Ts'o
2015-10-19 14:14 ` Frederic Weisbecker
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=20150813130303.GB29958@lerouge \
--to=fweisbec@gmail.com \
--cc=JBeulich@suse.com \
--cc=cl@linux.com \
--cc=cmetcalf@ezchip.com \
--cc=jgross@suse.com \
--cc=konrad.wilk@oracle.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.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