Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problèmes de scheduling avec Linux 2.6 #2663

Closed
vicuna opened this issue Jun 11, 2004 · 2 comments
Closed

Problèmes de scheduling avec Linux 2.6 #2663

vicuna opened this issue Jun 11, 2004 · 2 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Jun 11, 2004

Original bug ID: 2663
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Bonjour,

cf. ce mail de Christophe Raffalli sur caml-list il ya qqs mois:
http://caml.inria.fr/archives/200404/msg00266.html

Je lui avais répondu ceci:

Salut,

je pense que c'est dû au fait que le comportement de `sched_yield' a
changé dans le noyau 2.6: cf. http://lwn.net/Articles/31462/ ou
http://www.linux.org.uk/~davej/docs/post-halloween-2.6.txt dont voici
un extrait :

  • The behavior of sched_yield() changed a lot. A task that uses
    this system call should now expect to sleep for possibly a very
    long time. Tasks that do not really desire to give up the
    processor for a while should probably not make heavy use of this
    function. Unfortunately, some GUI programs (like Open Office)
    do make excessive use of this call and under load their
    performance is poor. It seems this new 2.6 behavior is optimal
    but some user-space applications may need fixing.

Or, si je ne me trompe, ocaml utilise ça pour l'implémentation de
Thread.yield. Je m'étais demandé si ça aurait une conséquence pour
ocaml, apparemment oui (j'ai pas encore essayé le 2.6).

maintenant que j'ai un noyau 2.6 (Fedora 2) sous la main, j'ai pu
tester et effectivement il y a l'air d'avoir un problème.

En faisant tourner ce programme (écrit pas Christophe) en compétition
avec un autre process (par ex. "md5sum /dev/zero"), on s'apercoit que
le prog. caml ne reçoit pratiquement pas de CPU.

,----
| let interface () =
| while true do
| let c = input_line stdin in
| print_string c; print_newline ();
| done
|
| let compute () =
| let i = ref 0 in
| while true do
| incr i;
| if (!i mod 1000000 = 0) then (print_int !i; print_newline ());
| done
|
| let _ = Thread.create interface ()
| let _ = compute ()
`----

Ce patch évite ce problème mais je ne sais pas trop si ça fait ce
qu'il faut vis-à-vis des signaux.

,----[ otherlibs/systhreads/thread_posix.ml ]
| (* Preemption *)
|
| -let preempt signal = yield()
| +let preempt = ignore
|
`----

--
Olivier

@vicuna
Copy link
Author

vicuna commented Jun 11, 2004

Comment author: administrator

Bonjour Olivier,

Merci pour les infos sur sched_yield() et le noyau 2.6.

Ce patch évite ce problème mais je ne sais pas trop si ça fait ce
qu'il faut vis-à-vis des signaux.

,----[ otherlibs/systhreads/thread_posix.ml ]
| (* Preemption *)
|
| -let preempt signal = yield()
| +let preempt = ignore
|
`----

Ben, ça désactive complètement la préemption entre threads Caml, donc
c'est un peu violent!

Moins violent: dans otherlibs/systhreads/posix.c, supprimer l'appel à
sched_yield() dans caml_thread_yield(). Ça m'intéresserait de savoir
comment se comporte le noyau 2.6 après cette modif lorsqu'on a
plusieurs threads Caml qui calculent beaucoup (p.ex. l'exemple de
Christophe avec 2 threads qui font compute(), ou plus). Est-ce que le
scheduling entre ces threads reste équitable?

Très cordialement,

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Jul 1, 2004

Comment author: administrator

Use of sched_yield() revised 2004-07-01 by XL

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant