ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@linux.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Mainlining PREEMPT_RT
Date: Wed, 14 Oct 2015 13:12:06 -0500 (CDT)	[thread overview]
Message-ID: <alpine.DEB.2.20.1510141303540.13301@east.gentwo.org> (raw)
In-Reply-To: <20151014112225.26771952@gandalf.local.home>

On Wed, 14 Oct 2015, Steven Rostedt wrote:

> Your use case is for large servers doing high frequency trading.

The use case is for regular servers wanting to use the processor
without OS interference in order to guarantee as much as possible a fast
"realtime" response (that term is used in this context by numerous users
of NOHZ. May be questionable I know but people use it that way).

> PREEMPT_RT works for that too, but for when the applications actually
> use the kernel. PREEMPT_RT is also used for embedded, where your use
> case does not fit.

The work on NOHZ was started and is still pushed by Chris Metcalf who is
working on embedded systems.

> Christoph, there's other use cases than what you want. This proposal is
> about PREEMPT_RT and there's a lot of use cases for that. Just because
> it's not what you need doesn't negate its usefulness.

Not seen it yet. Just references to customers that I have never worked
with. I keep heareing that RT is not useful because its soft realtime and
not guaranteed to keep its time constraints. Lets implement a real "hard"
realtime facility. Its possible if the processor is free of the OS.

> Christoph, feel free to ignore this thread and this topic. It's not for
> you. But there's others out there that don't use 1000 CPUs and find
> what we are doing quite useful.

Have been working with regular business class servers with two socket for
the last 8 years. The 1000s of cpus was a decade ago when I worked for
SGI.

This is regarding a common use case and AFAICT preempt and preempt_rt miss
the mark by increasing kernel code complexity significantly and thus
slowing things (cache footprint!!!) down instead of doing the obvious
which would be an enhanced NOHZ approach where a cpu can dedicate its full
power to a realtime load that may have to be fast and deterministic as the
hardware allows.

  reply	other threads:[~2015-10-14 18:12 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-13 16:42 Steven Rostedt
2015-10-13 17:33 ` Josh Triplett
2015-10-13 22:40 ` Rafael J. Wysocki
2015-10-13 22:19   ` Luis R. Rodriguez
2015-10-13 22:39     ` Steven Rostedt
2015-10-13 22:48       ` Luis R. Rodriguez
2015-10-13 23:04     ` Rafael J. Wysocki
2015-10-13 22:41       ` Luis R. Rodriguez
2015-10-14  7:35 ` Linus Walleij
2015-10-14 11:45 ` Christoph Lameter
2015-10-14 13:20   ` Steven Rostedt
2015-10-14 14:49     ` Christoph Lameter
2015-10-14 15:22       ` Steven Rostedt
2015-10-14 18:12         ` Christoph Lameter [this message]
2015-10-14 18:32           ` Steven Rostedt
2015-10-14 18:56             ` Christoph Lameter
2015-10-14 19:17               ` James Bottomley
2015-10-14 19:30               ` Tim Bird
2015-10-15  2:20                 ` Steven Rostedt
2015-10-15  9:05                 ` Thomas Gleixner
2015-10-14 20:24               ` Thomas Gleixner
2015-10-15 14:22                 ` Christoph Lameter
2015-10-15 15:13                   ` Steven Rostedt
2015-10-15 17:21                     ` Jan Kara
2015-10-15 18:09                       ` Steven Rostedt
2015-10-15 20:21                   ` Thomas Gleixner
2015-10-15 20:37                     ` Thomas Gleixner
2016-08-05 22:32 ` Darren Hart
2016-08-05 22:40   ` Darren Hart

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=alpine.DEB.2.20.1510141303540.13301@east.gentwo.org \
    --to=cl@linux.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=rostedt@goodmis.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