Re: [Lse-tech] RealTime Benchmarks

[Bill H. <ha...@au...>]

For realtime processes, what may be important is dispatch latency - how
long does it take to dispatch a realtime thread once it has been woke up.
A test for this could be to create N cpu bound SCHED_OTHER processes and one
realtime
process where N = the number of CPUs.  The realtime goes to sleep and wakes
up.

You would need to measure how long the realtime spent on the run queue waiting
to
get a CPU to run on.  Timestamp when adding and timestamp before giving up the
runqueue
lock in schedule() after selecting the realtime process. Compute the
difference in timestamp.

The latency will depend on :

(1) workload - where the CPU bound SCHED_OTHER process is - user space or
kernel
(2) where the wakeup occurred - at interrupt - on last CPU realtime ran on or
another CPU
(3) if there is an idle CPU in the system

N = the number of CPUs on the system.

Bill

Mike Kravetz wrote:

> Some time back, I asked about realtime benchmarks that could
> be used to test scheduler changes.  Since I received no
> recommendations, I decided to hack up the lat_ctx program of
> LMbench.  I simply added an option to specify 'realtime' and
> if set made all the 'token passing' tasks realtime.  My reasoning
> is that this would produce a simple context switching benchmark
> for realtime tasks.  This could then be used to verify that
> scheduler changes do not adversely impact realtime scheduling.
>
> Does this sound reasonable?
>
> FYI - The MultiQueue scheduler (patches posted on this (LSE)
> site) is up to 4X slower than then current Linux scheduler
> on SMP when benchmarked as described above.  Obviously, more
> investigation and work must be performed in this area.
>
> --
> Mike Kravetz                                  kr...@us...
> IBM Linux Technology Center       (we're not at Sequent anymore)
>
> _______________________________________________
> Lse-tech mailing list
> Lse...@li...
> https://lists.sourceforge.net/lists/listinfo/lse-tech