public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@linux.intel.com>
To: Christoph Lameter <cl@linux.com>
Cc: paulmck@linux.vnet.ibm.com, Peter Zijlstra <peterz@infradead.org>,
	Borislav Petkov <bp@alien8.de>,
	linux-kernel@vger.kernel.org, mingo@elte.hu,
	laijs@cn.fujitsu.com, dipankar@in.ibm.com,
	akpm@linux-foundation.org, mathieu.desnoyers@polymtl.ca,
	josh@joshtriplett.org, niv@us.ibm.com, tglx@linutronix.de,
	rostedt@goodmis.org, Valdis.Kletnieks@vt.edu,
	dhowells@redhat.com, edumazet@google.com, darren@dvhart.com,
	fweisbec@gmail.com, sbw@mit.edu,
	Kevin Hilman <khilman@linaro.org>
Subject: Re: [PATCH documentation 1/2] nohz1: Add documentation.
Date: Mon, 15 Apr 2013 09:41:19 -0700	[thread overview]
Message-ID: <516C2DAF.6010908@linux.intel.com> (raw)
In-Reply-To: <0000013e0e6cacbb-b7e44c6f-d551-49b9-aa07-62a4ee280ae7-000000@email.amazonses.com>

On 4/15/2013 9:00 AM, Christoph Lameter wrote:
> On Fri, 12 Apr 2013, Arjan van de Ven wrote:
>
>> but arguably, that's because of HRTIMERS more than NOHZ
>> (e.g. I bet we still turn off periodic even for nohz as long as hrtimers are
>> enabled)
>
> If we are able to only get rid of one timer tick on average with dynticks
> then I would think that is enough to justify having it on by default.
>
> If the scheduling period from the schduler is around 20ms then one may be
> able to save processing 20 timer ticks by going to htimers.
>
> The main issue with hrtimers is likely going to be that is it is too much
> effort for small timerframes less than 10ms. Could we  only switch off the
> timer tick if the next event is more than 10 ticks aways?
>

to put the "cost" into perspective; programming a timer in one-shot mode
is some math on the cpu (to go from kernel time to hardware time),
which is a multiply and a shift (or a divide), and then actually
programming the hardware, which is at the cost of (approximately) a cachemiss or two
(so give or take in the "hundreds" of cycles)
at least on moderately modern hardware (e.g. last few years)

not cheap. But also not INSANE expensive... and it breaks-even already if you only
save one or two cache misses elsewhere.


  reply	other threads:[~2013-04-15 16:41 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-11 16:05 [PATCH documentation 0/2] OS-jitter documentation Paul E. McKenney
2013-04-11 16:05 ` [PATCH documentation 1/2] nohz1: Add documentation Paul E. McKenney
2013-04-11 16:05   ` [PATCH documentation 2/2] kthread: Document ways of reducing OS jitter due to per-CPU kthreads Paul E. McKenney
2013-04-11 17:18     ` Randy Dunlap
2013-04-11 18:40       ` Paul E. McKenney
2013-04-11 20:09         ` Randy Dunlap
2013-04-11 21:00           ` Paul E. McKenney
2013-04-11 16:48   ` [PATCH documentation 1/2] nohz1: Add documentation Randy Dunlap
2013-04-11 17:09     ` Paul E. McKenney
2013-04-11 17:14   ` Arjan van de Ven
2013-04-11 18:27     ` Paul E. McKenney
2013-04-11 18:43       ` Dipankar Sarma
2013-04-11 19:14         ` Paul E. McKenney
2013-04-11 18:25   ` Borislav Petkov
2013-04-11 19:13     ` Paul E. McKenney
2013-04-11 20:19       ` Borislav Petkov
2013-04-11 21:01         ` Paul E. McKenney
2013-04-12  8:05       ` Peter Zijlstra
2013-04-12 17:54         ` Paul E. McKenney
2013-04-12 17:56           ` Arjan van de Ven
2013-04-12 20:39             ` Paul E. McKenney
2013-04-15 16:00             ` Christoph Lameter
2013-04-15 16:41               ` Arjan van de Ven [this message]
2013-04-15 16:53                 ` Christoph Lameter
2013-04-15 17:21                   ` Arjan van de Ven
2013-04-19 21:01   ` Kevin Hilman
2013-04-19 21:47     ` Paul E. McKenney
2013-04-27 13:26   ` 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=516C2DAF.6010908@linux.intel.com \
    --to=arjan@linux.intel.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=cl@linux.com \
    --cc=darren@dvhart.com \
    --cc=dhowells@redhat.com \
    --cc=dipankar@in.ibm.com \
    --cc=edumazet@google.com \
    --cc=fweisbec@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=khilman@linaro.org \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=niv@us.ibm.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sbw@mit.edu \
    --cc=tglx@linutronix.de \
    /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