public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: GeHao Kang <kanghao0928@gmail.com>
Cc: "Peter Zijlstra" <peterz@infradead.org>,
	"Chris Metcalf" <cmetcalf@mellanox.com>,
	"Frédéric Weisbecker" <fweisbec@gmail.com>,
	linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
	tglx@linutronix.de, mingo@kernel.org
Subject: Re: Context switch latency in tickless isolated CPU
Date: Mon, 22 Aug 2016 07:48:04 -0700	[thread overview]
Message-ID: <20160822144804.GB3482@linux.vnet.ibm.com> (raw)
In-Reply-To: <CANv7uPQ8rSU8foZv1GiLStiNX0Z6e+7tnRLJ_v2fspY5NZ8nwg@mail.gmail.com>

On Mon, Aug 22, 2016 at 05:40:03PM +0800, GeHao Kang wrote:
> On Sun, Aug 21, 2016 at 10:53 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
> > If latency is all you care about, one approach is to map the device
> > registers into userspace and do the I/O without assistance from the
> > kernel.
> In addition to the context switch latency, local interrupts are also
> closed during
> user_enter and user_exit of the context tracking. Therefore, the interrupt
> latency might be also increased on the isolated tickless CPU. That
> will degrade the
> real time performance. Are these two events determined?

Hmmm...  Why would you be taking interrupts on your isolated tickless
CPUs?  Doesn't that defeat the purpose of designating them as isolated
and tickless?

The key point being that effective use of NO_HZ_FULL requires
careful configuration and complete understanding of your workload.
And it is quite possible that you instead need to use something
other than NO_HZ_FULL.

If your question is instead "why must interrupts be disabled during
context tracking", I must defer to people who understand the x86
entry/exit code paths better than I do.

							Thanx, Paul

  reply	other threads:[~2016-08-22 14:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-17  6:26 Context switch latency in tickless isolated CPU GeHao Kang
2016-08-17 12:18 ` Chris Metcalf
2016-08-18  3:25   ` GeHao Kang
2016-08-19 12:34     ` Peter Zijlstra
2016-08-21 11:26       ` GeHao Kang
2016-08-21 14:53         ` Paul E. McKenney
2016-08-22  9:40           ` GeHao Kang
2016-08-22 14:48             ` Paul E. McKenney [this message]
2016-08-22 15:12               ` Mark Hounschell
2016-08-22 15:37                 ` Paul E. McKenney
2016-08-22 16:35                   ` Mark Hounschell

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=20160822144804.GB3482@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=cmetcalf@mellanox.com \
    --cc=fweisbec@gmail.com \
    --cc=kanghao0928@gmail.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --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