linux-kernel - Performance issue SCHED_OTHER over SCHED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Thu, 12 Mar 2009 13:43:01 +0100
From:	Thanh Ly <thanh.ly@...ica.com>
To:	linux-kernel@...r.kernel.org
Subject: Performance issue SCHED_OTHER over SCHED_RR; bug in real time
 policy?

Dear Linux GURU's,

We've been experimenting with the scheduler for quite a time and there
is one thing which bothers us. For some reason we cannot explain why the
SCHED_FIFO and SCHED_RR is slower than SCHED_OTHER.

For our experiment We've created a simple function which calculates the
fibonacci number sequence using a for loop (1 billion loops). We've
measured the wall time and the cpu usage using getrusage().

We've run this program on a dual-core Intel CPU machine (Intel(R)
Core(TM)2 Duo CPU T7500  @ 2.20GHz) running kernel version
2.6.27-13-generic (Ubuntu 8.10).

First only 1 thread will calculate the fibonacci number and after that 5
threads will each do the same calculations. Each test we've executed 5
times. The measured time has been written to a log file. All threads are
executed with an equal priority (inherited from process).

Summary of log analysis:
Executed with 1 thread

Average time->      Walltime     Ruage time
------------------------------------------------
SCHED_OTHER           4.7s          4.7s
SCHED_FIFO*           4.7s          4.7s        
SCHED_RR*             4.7s          4.7s

* However for 2 measurements of FIFO and 1 of RR
  a value of 13s has been measured!!!

Executed with 5 threads

Average time->      Walltime     Ruage time
------------------------------------------------
SCHED_OTHER           12.5s         5.0s
SCHED_FIFO**          15.1s         5.0s        
SCHED_RR***           15.5s         5.6s

** In run 3 thread 3/4 has a larger time (5.6s);
   Each fifth thread has a time of 4.7s being
   equal to the case of 1 thread execution.
*** Within each run the times are fairly the same
    with an occasional outlier.
    Between the runs the walltime jitters between
    13.7s and 16.3s

Conclusions:
1) There seems to be a bug in the real-time scheduling policies.
2) Despite the similarity between SCHED_OTHER and SCHED_RR
   the performance of SCHED_OTHER is better than SCHED_RR
   even though SCHED_RR is a 'real-time' policy (with always
   a higher priority!).

If our conclusion is correct has this bug already been reported?
Is there an explanation for the better performance of SCHED_OTHER
over SCHED_RR?

With regards,

Thanh Ly

Please help Logica to respect the environment by not printing this email  /  Merci d'aider Logica à préserver l'environnement en évitant d'imprimer ce mail /  Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei die Umwelt zu schuetzen  /  Por favor ajude a Logica a respeitar o ambiente não imprimindo este correio electrónico.

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

View attachment "main.c" of type "text/x-csrc" (5848 bytes)

View attachment "total.log" of type "text/x-log" (5545 bytes)