Re: [Caml-list] Thread and kernel 2.6 pb still there in CVS

[Xavier Leroy <Xavier.Leroy@inria.fr>]

> I tried to submit a change in vouillon's entry in the bug tracking 
> system (classed as not a bug because can not reproduce), but as I am not 
> sure it worked, So I also post this here

You should be grateful to Olivier Andrieu, who actually cared to
submit a bug report along with useful info on 2.6 kernels.

> In the latest CVS of ocaml there is still the periodic call Thread.yield 
> (through a sigalarm) in thread_posix.ml

Yes, and that is necessary to get preemptive scheduling.  Without this
periodic Thread.yield, a thread that performs no I/O and no
inter-thread communications would prevent all other Caml threads from
running at all.

> This implies that a threaded OCaml program ON A LINUX KERNEL 2.6 (at 
> least 2.6.3 on Mandrake 10, but probaby all 2.6) gets very little CPU 
> when another process is running (the usual figure is 10% CPU for the 
> threaded OCaml program against 90% for another program)

Thread.yield does three things:
   - release the global Caml mutex, giving other Caml threads a chance
     to grab it and run;
   - call sched_yield() to suggest the kernel scheduler that now is
     a good time to schedule another thread;
   - re-acquire the global Caml mutex before returning to the caller.

The 2.6 Linux kernels changed the behavior of sched_yield() in a way
that causes the unfairness you observed.  Other threaded applications
are affected, including Open Office (!).  My belief is that it's
really a bug in 2.6 kernels and that the new behavior of sched_yield(),
while technically conformant to the POSIX specs, lowers the quality of
implementation quite a lot.

(I seem to remember from my LinuxThreads development days that this
isn't the first time the kernel developers broke sched_yield(), then
realized their error.)

The question I'm currently investigating is whether the call to
sched_yield() can be omitted, as it's just a scheduling hint.  Initial
experiments suggested that this would hurt fairness (in Caml thread
scheduling) quite a lot on all platforms other than Linux 2.6.
More careful experiments that I'm currently conducting suggest that it
might not be so bad.  One can also play games where sched_yield()
isn't called if there are no other Caml threads waiting for the global
Caml mutex.

In summary, a solution will eventually be found, but please be
patient, and submit a bug report next time.

- Xavier Leroy

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners