[Ksummit-discuss] [TECH TOPIC] Mainlining PREEMPT_RT
Steven Rostedt
rostedt at goodmis.org
Wed Oct 14 18:32:44 UTC 2015
On Wed, 14 Oct 2015 13:12:06 -0500 (CDT)
Christoph Lameter <cl at 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
More information about the Ksummit-discuss
mailing list