Re: Some benchmark results

[Bernhard Schiffner <bernhard@schiffner-limbach.de>]

Am Montag, 25. August 2014, 11:02:32 schrieb Daniel Wagner:
> Hi,
> 
> I wanted to know how good or bad mainline vs RT is, therefore I let
> MMTests torture my laptop for a while. I selected a few of the supported
> benchmarks by MMTests in order to keep to a reasonable time frame.
> 
> The aim was to see the impact of normal (no RT) workloads with different
> preempt configurations on mainline and RT patched kernel. I tried to not
> to change other configuration flags except the preempt one. There are
> some small difference due to dependencies but the rest looks ok to me.
> 
> http://www.monom.org/rt/mmtests/
> 
> Suggestion, improvements, comments?
> 
> cheers,
> daniel
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Daniel,

I had a first look at the above mentioned page.

The thing I'am complety missing in the huge amount of numbers is: What is your 
demand, your primary topic to solve in or with RT?
And as I interprete the numbers: a RT kernel is a little bit more CPU-hungry 
then normal and this is nothing new.
---

Until now it's usual to characterize RT performance in terms of (missed) 
maximum latencies.

You define your specialized workload, run it with RT priorities and check if 
it fits its demands. BTW you can verify and document this over the lifetime of 
your hardware/software combination.
If misses happen it is mostly possible to track the problem down to the 
culprit piece of soft- or hardware. If so, an iteration process starts 
hopefully before real damage happens.

A measure to "stress" your workload in a conceptional phase is putting more or 
less unrelated software on your machine until you quasi saturate their 
ressources (I/O, interrupt, drivers, schedulers, CPU, memory, network). If 
your primary workload survives you'll get a much better feeling but still no 
guarantees.

Next is to understand and accept that certain parts even of a RT kernel are 
_not_ designed to guarantee limited latencies (memory allocation, disk-IO, 
suspend-resume comes to mind). If you trigger them in your RT task: back to 
start. If you trigger them elsewhere: perhaps it still works.

I hope this helps to understand the situation a little bit better.
Nevertheless thanks for the patience to do and document all the tests.


Bernhard