LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Rik van Riel <riel@redhat.com>,
	kvm@vger.kernel.org, borntraeger@de.ibm.com,
	linux-kernel@vger.kernel.org, mtosatti@redhat.com,
	mingo@kernel.orgm, ak@linux.intel.com, oleg@redhat.com,
	masami.hiramatsu.pt@hitachi.com, lcapitulino@redhat.com,
	pbonzini@redhat.com
Subject: Re: [PATCH 1/5] rcu,nohz: add state parameter to context_tracking_user_enter/exit
Date: Sat, 7 Feb 2015 12:06:24 -0800	[thread overview]
Message-ID: <20150207200624.GZ5418@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150207083036.GA24538@lerouge>

On Sat, Feb 07, 2015 at 09:30:41AM +0100, Frederic Weisbecker wrote:
> On Fri, Feb 06, 2015 at 11:14:53PM -0800, Paul E. McKenney wrote:
> > On Fri, Feb 06, 2015 at 10:34:21PM -0800, Paul E. McKenney wrote:
> > > On Fri, Feb 06, 2015 at 10:53:34PM -0500, Rik van Riel wrote:
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA1
> > > > 
> > > > On 02/06/2015 06:15 PM, Frederic Weisbecker wrote:
> > > > 
> > > > > Just a few things then:
> > > > > 
> > > > > 1) In this case rename context_tracking_user_enter/exit() to 
> > > > > context_tracking_enter() and context_tracking_exit(), since it's
> > > > > not anymore about user only but about any generic context.
> > > > > 
> > > > > 2) We have the "WARN_ON_ONCE(!current->mm);" condition that is a
> > > > > debug check specific to userspace transitions because kernel
> > > > > threads aren't expected to resume to userspace. Can we also expect
> > > > > that we never switch to/from guest from a kernel thread? AFAICS
> > > > > this happens from an ioctl (thus user task) in x86 for kvm. But I
> > > > > only know this case.
> > > > > 
> > > > > 3) You might want to update a few comments that assume we only deal
> > > > > with userspace transitions.
> > > > > 
> > > > > 4) trace_user_enter/exit() should stay user-transitions specific.
> > > > 
> > > > Paul, would you like me to send follow-up patches with the cleanups
> > > > suggested by Frederic, or would you prefer me to send a new series
> > > > with the cleanups integrated?
> > > 
> > > I would prefer a new series, in order to prevent possible future
> > > confusion.
> > 
> > Of course, if Frederic would rather push them himself, I am fine with
> > that.  And in that case, you should ask him for his preferences, which
> > just might differ from mine.  ;-)
> 
> I prefer a new series too. Now whether you or me take the patches, I don't mind
> either way :-)
> 
> Also I wonder how this feature is going to be enabled. Will it be enabled on
> full dynticks or should it be a seperate feature depending on full dynticks?
> Or even just CONFIG_RCU_USER_EQS? Because I'm still unclear about how and what
> this is used, if it involves full dynticks or only RCU extended quiescent states.

Well, we certainly need it documented.  And validation considerations
would push for keeping the number of possible combinations low, while
paranoia about added feature would push for having it be separately
enabled.  And if distros are going to enable this at build time, we
either need -serious- validation or a way to disable at boot time.

On the desired/required combinations of features, let's see...

If I understand this completely, which I probably don't, we have the
following considerations:

o	NO_HZ_FULL: Needed to get rid of the scheduling-clock interrupt
	during guest execution, though I am not sure whether we really
	have that completely wired up with this patch set.  Regardless,
	Rik, for your use case, do you care about whether or not the
	guest gets interrupted by the host's scheduling-clock interrupts?
	(Based on discussion in this thread, my guess is "yes".)

o	RCU_NOCB_CPUS: Implied by NO_HZ_FULL, but only on CPUs actually
	enabled for NO_HZ_FULL operation, either by NO_HZ_FULL_ALL
	at build time or by nohz_full= at boot time.  Needed to avoid
	interrupting the guest with host RCU callback invocation.
	Rik, does your use case care about guests being interrupted
	by RCU callback invocation?  (Based on discussion in this thread,
	my guess is "yes".)

o	RCU_USER_EQS: Implied by NO_HZ_FULL, and I would have to go look
	to see what relation this has to nohz_full=.  Needed for RCU to be
	able to recognize userspace-execution quiescent states on a given
	CPU without disturbing that CPU.  Unless I am missing something
	subtle, you have to have this for this patch series to make sense.

If my guesses are correct, the best approach would be to have this
new mode of operation implied by NO_HZ_FULL.  The patches seem simple
enough that killer validation should be practical, which would avoid
further complication of the Kconfig combinatorial space.

So, are my guesses correct?

							Thanx, Paul


  parent reply	other threads:[~2015-02-07 20:06 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-05 20:23 [PATCH v2 0/5] rcu,nohz,kvm: use RCU extended quiescent state when running KVM guest riel
2015-02-05 20:23 ` [PATCH 1/5] rcu,nohz: add state parameter to context_tracking_user_enter/exit riel
2015-02-05 23:55   ` Paul E. McKenney
2015-02-06 10:15     ` Paolo Bonzini
2015-02-06 13:41       ` Paul E. McKenney
2015-02-06 17:22   ` Frederic Weisbecker
2015-02-06 18:20     ` Rik van Riel
2015-02-06 18:23       ` Frederic Weisbecker
2015-02-06 18:51         ` Rik van Riel
2015-02-06 23:15           ` Frederic Weisbecker
2015-02-07  3:53             ` Rik van Riel
2015-02-07  6:34               ` Paul E. McKenney
2015-02-07  7:14                 ` Paul E. McKenney
2015-02-07  8:30                   ` Frederic Weisbecker
2015-02-07 11:29                     ` Rik van Riel
2015-02-07 20:06                     ` Paul E. McKenney [this message]
2015-02-09 15:42                       ` Rik van Riel
2015-02-05 20:23 ` [PATCH 2/5] rcu,nohz: run vtime_user_enter/exit only when state == IN_USER riel
2015-02-05 20:23 ` [PATCH 3/5] nohz,kvm: export context_tracking_user_enter/exit riel
2015-02-05 23:55   ` Paul E. McKenney
2015-02-05 20:23 ` [PATCH 4/5] kvm,rcu,nohz: use RCU extended quiescent state when running KVM guest riel
2015-02-05 23:56   ` Paul E. McKenney
2015-02-06 18:01   ` Frederic Weisbecker
2015-02-06 23:24   ` Frederic Weisbecker
2015-02-05 20:23 ` [PATCH 5/5] nohz: add stub context_tracking_is_enabled riel
2015-02-05 23:56   ` Paul E. McKenney
2015-02-06 13:46 ` [PATCH v2 0/5] rcu,nohz,kvm: use RCU extended quiescent state when running KVM guest Frederic Weisbecker
2015-02-06 13:50   ` Paolo Bonzini
2015-02-06 16:19     ` Paul E. McKenney
2015-02-06 18:09     ` Frederic Weisbecker
2015-02-06 14:56   ` Rik van Riel
2015-02-06 18:05     ` Frederic Weisbecker
2015-02-06 15:00 ` Christian Borntraeger
2015-02-06 18:20   ` 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=20150207200624.GZ5418@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=ak@linux.intel.com \
    --cc=borntraeger@de.ibm.com \
    --cc=fweisbec@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=lcapitulino@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@kernel.orgm \
    --cc=mtosatti@redhat.com \
    --cc=oleg@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=riel@redhat.com \
    --subject='Re: [PATCH 1/5] rcu,nohz: add state parameter to context_tracking_user_enter/exit' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).