Re: [Ksummit-discuss] [TECH TOPIC] Mainlining PREEMPT_RT

[Steven Rostedt <rostedt@goodmis.org>]

On Wed, 14 Oct 2015 13:12:06 -0500 (CDT)
Christoph Lameter <cl@linux.com> wrote:

> 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

real-time does not mean real-fast.

> 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.

I never said that NO_HZ_FULL was not appropriate for embedded. But it's
also not real-time.

> 
> > 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.

If PREEMPT_RT is not the way to go, then why did several companies just
invest into getting it mainlined?

> 
> > 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.

Again, real-time does not mean real-fast. How do you handle priority
inversion? How do you handle outliers? Which the Linux kernel has many
huge outliers if things are not handled correctly, which PREEMPT_RT
solve (making it, by the way, a hard real time design).  If you can
accept a single outlier, then that's soft real-time, and you are
talking about something completely different.

Hard real-time is about worse case latency, not the average latency.
That's called "soft real-time"

-- Steve