You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 2663 Reporter: administrator Status: closed Resolution: fixed Priority: normal Severity: minor Category: ~DO NOT USE (was: OCaml general)
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.
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?
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:
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
The text was updated successfully, but these errors were encountered: