public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Borislav Petkov <bp@alien8.de>,
	Li Zhong <zhong@linux.vnet.ibm.com>,
	Mike Galbraith <efault@gmx.de>, Kevin Hilman <khilman@linaro.org>
Subject: Re: [PATCH 07/18] nohz: Selectively enable context tracking on full dynticks CPUs
Date: Fri, 19 Jul 2013 00:13:47 +0200	[thread overview]
Message-ID: <20130718221346.GE7398@somewhere> (raw)
In-Reply-To: <1374085637.6458.170.camel@gandalf.local.home>

On Wed, Jul 17, 2013 at 02:27:17PM -0400, Steven Rostedt wrote:
> On Wed, 2013-07-17 at 18:44 +0200, Frederic Weisbecker wrote:
> > The code is ready to do so in the context tracking subsystem, now
> 
> "do so"? Do what?

It's referring to the patch title. The code is ready to selectively
enable context tracking on the CPUs.

I see many changelogs that use that kind of style where the title
of the patch is considered as the 1st line of the changelog. That's
convenient because it avoids the need to rephrase the title in the
changelog.

But may be the reference to the title is not obvious. if you prefer
I can expand the "do so" here.

> 
> > we just need to pass our cpu range selection to it from the
> 
> Pass cpu range selection to what?
> 
> Pronouns are evil in technical documentation.

How about:

"""
The code in the context tracking subsystem is ready to selectively
enable its tracking on specificied CPU ranges instead of inconditionally
force it on all CPUs.

What we need to do now is to pass the desired CPU ranges to track from
the full dynticks subsystem, according to the ranges specified in the
"nohz_full=" boot option.
""" 

> > diff --git a/include/linux/context_tracking.h b/include/linux/context_tracking.h
> > index 12045ce..2c2b73aa 100644
> > --- a/include/linux/context_tracking.h
> > +++ b/include/linux/context_tracking.h
> > @@ -34,6 +34,8 @@ static inline bool context_tracking_active(void)
> >  	return __this_cpu_read(context_tracking.active);
> >  }
> >  
> > +extern void context_tracking_cpu_set(int cpu);
> > +
> >  extern void user_enter(void);
> >  extern void user_exit(void);
> >  
> > diff --git a/init/Kconfig b/init/Kconfig
> > index 247084b..914da3f 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -527,7 +527,7 @@ config RCU_USER_QS
> >  config CONTEXT_TRACKING_FORCE
> >  	bool "Force context tracking"
> >  	depends on CONTEXT_TRACKING
> > -	default CONTEXT_TRACKING
> > +	default y if !NO_HZ_FULL
> 
> Why the if !NO_HZ_FULL?
> 
> That selects this anyway. Oh wait, you changed this.

Yeah that's probably confusing. Ok lets consider a system with:

     CONTEXT_TRACKING=y

By default it doesn't track any CPU, it's inactive unless you set:

     CONTEXT_TRACKING_FORCE=y

In this case, all CPUs are tracked.

The full dynticks subsystem was supposed to pass its CPU range to context
tracking such that it activates the tracking only on the relevant CPUs.

But the context tracking code was merged before full dynticks. So nothing
was there to enabled CPUs on context tracking initially. So we needed
CONTEXT_TRACKING_FORCE for testing.

Then later we merged full dynticks. But we got lazy and rushed and instead of
selecting the CPUs to track on runtime from the full dynticks subsystem to
the context tracking subsystem, we forced CONTEXT_TRACKING_FORCE=y when
NO_HZ_FULL=y. Then using runtime selection became a TODO.

Now these patches handle that TODO and full dynticks passes its range to
contex tracking.

Now one could argue why we keep CONTEXT_TRACKING_FORCE around, since we
have full dynticks and NO_HZ_FULL_ALL for wide automated testing.

This is because CONTEXT_TRACKING is not sufficient for NO_HZ_FULL alone.
Especially because of the 64bits requirement that I need to drop after
careful review of any use of cputime_t. But anyway, CONTEXT_TRACKING_FORCE
is still handy to keep around for archs that want support for nohz full
but don't yet meet all dependencies.

Thanks.

  reply	other threads:[~2013-07-18 22:13 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-17 16:44 [PATCH 00/18] nohz patches for 3.12 preview Frederic Weisbecker
2013-07-17 16:44 ` [PATCH 01/18] nohz: Do not warn about unstable tsc unless user uses nohz_full Frederic Weisbecker
2013-07-17 16:44 ` [PATCH 02/18] nohz: fix compile warning in tick_nohz_init() Frederic Weisbecker
2013-07-17 16:44 ` [PATCH 03/18] sched: Consolidate open coded preemptible() checks Frederic Weisbecker
2013-07-17 16:44 ` [PATCH 04/18] context_tracing: Fix guest accounting with native vtime Frederic Weisbecker
2013-07-17 16:44 ` [PATCH 05/18] vtime: Update a few comments Frederic Weisbecker
2013-07-17 17:57   ` Steven Rostedt
2013-07-18 21:30     ` Frederic Weisbecker
2013-07-17 16:44 ` [PATCH 06/18] context_tracking: Fix runtime CPU off-case Frederic Weisbecker
2013-07-17 16:44 ` [PATCH 07/18] nohz: Selectively enable context tracking on full dynticks CPUs Frederic Weisbecker
2013-07-17 18:27   ` Steven Rostedt
2013-07-18 22:13     ` Frederic Weisbecker [this message]
2013-07-18 22:51       ` Steven Rostedt
2013-07-19 14:19         ` Frederic Weisbecker
2013-07-17 16:44 ` [PATCH 08/18] context_tracking: Ground setup for static key use Frederic Weisbecker
2013-07-17 16:44 ` [PATCH 09/18] context_tracking: Optimize main APIs off case with static key Frederic Weisbecker
2013-07-17 16:44 ` [PATCH 10/18] context_tracking: Optimize context switch off case with static keys Frederic Weisbecker
2013-07-17 16:44 ` [PATCH 11/18] context_tracking: User/kernel broundary cross trace events Frederic Weisbecker
2013-07-17 16:44 ` [PATCH 12/18] vtime: Remove a few unneeded generic vtime state checks Frederic Weisbecker
2013-07-17 16:44 ` [PATCH 13/18] vtime: Fix racy cputime delta update Frederic Weisbecker
2013-07-17 16:44 ` [PATCH 14/18] context_tracking: Split low level state headers Frederic Weisbecker
2013-07-17 16:44 ` [PATCH 15/18] vtime: Describe overriden functions in dedicated arch headers Frederic Weisbecker
2013-07-17 16:44 ` [PATCH 16/18] vtime: Optimize full dynticks accounting off case with static keys Frederic Weisbecker
2013-07-17 16:44 ` [PATCH 17/18] vtime: Always scale generic vtime accounting results Frederic Weisbecker
2013-07-17 16:44 ` [PATCH 18/18] vtime: Always debug check snapshot source _before_ updating it 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=20130718221346.GE7398@somewhere \
    --to=fweisbec@gmail.com \
    --cc=bp@alien8.de \
    --cc=efault@gmx.de \
    --cc=khilman@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=zhong@linux.vnet.ibm.com \
    /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