2.6.1 Scheduler Latency Measurements (Preemption diabled/enabled)

2.6.1 Scheduler Latency Measurements (Preemption diabled/enabled)

[Christoph Stueckjuergen]

Hi,

I performed a series of measurements comparing scheduler latency of a 2.6.1 
kernel with preemption enabled and disabled on an AMD Elan (i486 compatible) 
with 133 Mhz clock frequency.

The measurements were performed with a kernel module and a user mode process 
that communicate via a character device interface. The user mode process uses 
a blocking read() call to obtain data from the kernel. The kernel module 
reads the system time every 10 ms by calling do_gettimeofday(), wakes up the 
sleeping user mode process and passes the system time to it. After having 
received the system time from the kernel, the user mode process reads the 
system time by calling gettimeofday() and is thus able to determine the 
scheduler latency by subtracting the two times. The user mode process is run 
with the SCHED_FIFO scheduling policy.

Measurements were carried out on a „loaded“ and an „unloaded“ system. The 
„load“ was created by a process that continuously writes data to the serial 
interface /dev/ttyS0.

The results are:
"loaded" system, 10.000 samples
average scheduler latency (preemption enabled / disabled): 170 us / 232 us
minimum scheduler latency (preemption enabled / disabled): 49 us / 43 us
maximum scheduler latency (preemption enabled / disabled): 840 us / 1063 us

"unloaded" system, 10.000 samples
average scheduler latency (preemption enabled / disabled): 50 us / 44 us
minimum scheduler latency (preemption enabled / disabled): 46 us / 41 us
maximum scheduler latency (preemption enabled / disabled): 233 us / 215 us

Any help in interpreting the data would be highly appreciated. Especially:
- Why does preemption lead to a higher minimum scheduler latency in the loaded 
case?
- Why does preemption worsen scheduler latency on the unloaded system?

Best regards,
Christoph

PS: I am not subscribed, please CC me if you answer!

Re: 2.6.1 Scheduler Latency Measurements (Preemption diabled/enabled)

[Nick Piggin]

Christoph Stueckjuergen wrote:

>Hi,
>
>I performed a series of measurements comparing scheduler latency of a 2.6.1 
>kernel with preemption enabled and disabled on an AMD Elan (i486 compatible) 
>with 133 Mhz clock frequency.
>
>The measurements were performed with a kernel module and a user mode process 
>that communicate via a character device interface. The user mode process uses 
>a blocking read() call to obtain data from the kernel. The kernel module 
>reads the system time every 10 ms by calling do_gettimeofday(), wakes up the 
>sleeping user mode process and passes the system time to it. After having 
>received the system time from the kernel, the user mode process reads the 
>system time by calling gettimeofday() and is thus able to determine the 
>scheduler latency by subtracting the two times. The user mode process is run 
>with the SCHED_FIFO scheduling policy.
>
>Measurements were carried out on a „loaded“ and an „unloaded“ system. The 
>„load“ was created by a process that continuously writes data to the serial 
>interface /dev/ttyS0.
>
>The results are:
>"loaded" system, 10.000 samples
>average scheduler latency (preemption enabled / disabled): 170 us / 232 us
>minimum scheduler latency (preemption enabled / disabled): 49 us / 43 us
>maximum scheduler latency (preemption enabled / disabled): 840 us / 1063 us
>
>"unloaded" system, 10.000 samples
>average scheduler latency (preemption enabled / disabled): 50 us / 44 us
>minimum scheduler latency (preemption enabled / disabled): 46 us / 41 us
>maximum scheduler latency (preemption enabled / disabled): 233 us / 215 us
>
>Any help in interpreting the data would be highly appreciated. Especially:
>- Why does preemption lead to a higher minimum scheduler latency in the loaded 
>case?
>- Why does preemption worsen scheduler latency on the unloaded system?
>
>

Because it adds a small amount of overhead. What you are paying for
is the improvement in worst case latencies. Looks like it is exactly
what you would expect.

Re: 2.6.1 Scheduler Latency Measurements (Preemption diabled/enabled)

[Robert Love]

On Tue, 2004-02-03 at 17:24 +0100, Christoph Stueckjuergen wrote:

> The results are:
> "loaded" system, 10.000 samples
> average scheduler latency (preemption enabled / disabled): 170 us / 232 us
> minimum scheduler latency (preemption enabled / disabled): 49 us / 43 us
> maximum scheduler latency (preemption enabled / disabled): 840 us / 1063 us
> 
> "unloaded" system, 10.000 samples
> average scheduler latency (preemption enabled / disabled): 50 us / 44 us
> minimum scheduler latency (preemption enabled / disabled): 46 us / 41 us
> maximum scheduler latency (preemption enabled / disabled): 233 us / 215 us
> 
> Any help in interpreting the data would be highly appreciated. Especially:
> - Why does preemption lead to a higher minimum scheduler latency in the loaded 
> case?
>
> - Why does preemption worsen scheduler latency on the unloaded system?

Overhead, I guess - the place where preemption ought to pay off is with
worst-case latency, where your results do show an improvement.

That said, I would of expected slightly better numbers.  Although, note
that you are not measuring latency, you are measuring jitter.

Latency is time actual minus time expected.  It thus requires some
notion of the absolute expected time.  Without hardware support you
generally cannot measure this.

Jitter is measuring the time between successive events subtracted by the
expected duration, e.g. actual duration minus expected duration.  It
requires no knowledge of the absolute time.

Jitter tends to approximate latency, so that is OK, but all it really
measures is the variance in results (the "jitter" between the
durations).

Most people mix the two up.

	Robert Love

Re: 2.6.1 Scheduler Latency Measurements (Preemption diabled/enabled)

[Bill Davidsen]

Christoph Stueckjuergen wrote:
> Hi,
> 
> I performed a series of measurements comparing scheduler latency of a 2.6.1 
> kernel with preemption enabled and disabled on an AMD Elan (i486 compatible) 
> with 133 Mhz clock frequency.
> 
> The measurements were performed with a kernel module and a user mode process 
> that communicate via a character device interface. The user mode process uses 
> a blocking read() call to obtain data from the kernel. The kernel module 
> reads the system time every 10 ms by calling do_gettimeofday(), wakes up the 
> sleeping user mode process and passes the system time to it. After having 
> received the system time from the kernel, the user mode process reads the 
> system time by calling gettimeofday() and is thus able to determine the 
> scheduler latency by subtracting the two times. The user mode process is run 
> with the SCHED_FIFO scheduling policy.
> 
> Measurements were carried out on a „loaded“ and an „unloaded“ system. The 
> „load“ was created by a process that continuously writes data to the serial 
> interface /dev/ttyS0.
> 
> The results are:
> "loaded" system, 10.000 samples
> average scheduler latency (preemption enabled / disabled): 170 us / 232 us
> minimum scheduler latency (preemption enabled / disabled): 49 us / 43 us
> maximum scheduler latency (preemption enabled / disabled): 840 us / 1063 us
> 
> "unloaded" system, 10.000 samples
> average scheduler latency (preemption enabled / disabled): 50 us / 44 us
> minimum scheduler latency (preemption enabled / disabled): 46 us / 41 us
> maximum scheduler latency (preemption enabled / disabled): 233 us / 215 us
> 
> Any help in interpreting the data would be highly appreciated. Especially:
> - Why does preemption lead to a higher minimum scheduler latency in the loaded 
> case?
> - Why does preemption worsen scheduler latency on the unloaded system?
> 
> Best regards,
> Christoph
> 
> PS: I am not subscribed, please CC me if you answer!

Have you considered repeating your test on 2.6.3-rc3-mm1 or similar with 
all of the most recent thinking on scheduling?

-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979

Re: 2.6.1 Scheduler Latency Measurements (Preemption diabled/enabled)

[Nick Piggin]

Bill Davidsen wrote:

> Christoph Stueckjuergen wrote:


snip

>>
>> PS: I am not subscribed, please CC me if you answer!
>
>
> Have you considered repeating your test on 2.6.3-rc3-mm1 or similar 
> with all of the most recent thinking on scheduling?
>

They shouldn't make a difference here. Christoph is using
realtime scheduling, so he's really measuring preempt off
time + context switch overhead. The actual scheduler can't
really help here.

Re: 2.6.1 Scheduler Latency Measurements (Preemption diabled/enabled)

[Christoph Stueckjuergen]

Am Mittwoch, 18. Februar 2004 05:07 schrieb Nick Piggin:
> > Have you considered repeating your test on 2.6.3-rc3-mm1 or similar
> > with all of the most recent thinking on scheduling?
>
> They shouldn't make a difference here. Christoph is using
> realtime scheduling, so he's really measuring preempt off
> time + context switch overhead. The actual scheduler can't
> really help here.

I set up these measurements for a course on Embedded Linux and I must repeat 
them with a current kernel anyway when the course actually starts. If 
anything changes, I will let you know!

Christoph

Re: 2.6.1 Scheduler Latency Measurements (Preemption diabled/enabled)

[Roger Larsson]

Christoph Stueckjuergen wrote:

>Hi,
>
>I performed a series of measurements comparing scheduler latency of a 2.6.1 
>kernel with preemption enabled and disabled on an AMD Elan (i486 compatible) 
>with 133 Mhz clock frequency.

OK, then you have worse hardware than I had when I started to measure
latency :-)

> - - - interesting way of trigger and measure deleted - - -

> The results are:
> "loaded" system, 10.000 samples
> average scheduler latency (preemption enabled / disabled): 170 us / 232 us
> minimum scheduler latency (preemption enabled / disabled): 49 us / 43 us
> maximum scheduler latency (preemption enabled / disabled): 840 us / 1063 us
> 
> "unloaded" system, 10.000 samples
> average scheduler latency (preemption enabled / disabled): 50 us / 44 us
> minimum scheduler latency (preemption enabled / disabled): 46 us / 41 us
> maximum scheduler latency (preemption enabled / disabled): 233 us / 215 us
> 

Robert Love said:
> That said, I would of expected slightly better numbers.

I would say that the numbers are quite good :-)
For comparation check
  http://www.gardena.net/benno/linux/audio/

There are some load tests there that you can use
to generate load: disk access, memory pressure, X11, ...

Note that more memory can result in worse latency, longer linked lists
to walk...

/RogerL

-- 
Roger Larsson
Skellefteå
Sweden