[Caml-list] Scheduling thread problem kernel 2.6

[Caml-list] Scheduling thread problem kernel 2.6

[Christophe Raffalli]

Message posted to comp.os.linux.misc and caml-list.

I am having a scheduling problem with a Caml program that uses two threads:
- one CPU intensive thread
- one interface thread (using Glut + OpenGL) and often doing nothing

The problem is that the CPU intensive thread never gets more than 50% 
(near 100% expected) of the CPU (usually 20 to 30%). Moreover the thread 
only get less than 20% (near 50% expected) if another CPU intensive 
process is running.

I suspect that the scheduling algorithm uses the behaviour of the 
interface thread to predict (wrongly) that both threads need little CPU. 
This seems confirmed by the fact that call to Thread.yield in the 
interface thread slow down the CPU intensive thread !

The problem exists with all versions of kernel 2.6 I tried (from 2.6.3 
to 2.6.5 unpatched and the Mandrake 2.6.3). Everything is fine with a 
kernel 2.4.

Playing with SCHEDULING_SCOPE_SYSTEM and SCHEDULING_SCOPE_PROCESS 
changes nothing.

Any hint ?



-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

-------------------
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

Re: [Caml-list] Scheduling thread problem kernel 2.6

[David Brown]

On Tue, Apr 13, 2004 at 09:57:35AM +0200, Christophe Raffalli wrote:
> 
> Message posted to comp.os.linux.misc and caml-list.
> 
> I am having a scheduling problem with a Caml program that uses two threads:
> - one CPU intensive thread
> - one interface thread (using Glut + OpenGL) and often doing nothing

What wrappers are you using to call to the interface.  Are there any
blocking calls in it?  You might check the wrappers to these calls to
make sure that they call enter_blocking_section, and
leave_blocking_section.  Otherwise, the entire ocaml runtime will be
blocked.

Dave

-------------------
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

Re: [Caml-list] Scheduling thread problem kernel 2.6

[Christophe Raffalli]

[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]

David Brown wrote:
> On Tue, Apr 13, 2004 at 09:57:35AM +0200, Christophe Raffalli wrote:
> 
>>Message posted to comp.os.linux.misc and caml-list.
>>
>>I am having a scheduling problem with a Caml program that uses two threads:
>>- one CPU intensive thread
>>- one interface thread (using Glut + OpenGL) and often doing nothing
> 
> 
> What wrappers are you using to call to the interface.  Are there any
> blocking calls in it?  You might check the wrappers to these calls to
> make sure that they call enter_blocking_section, and
> leave_blocking_section.  Otherwise, the entire ocaml runtime will be
> blocked.

I do not understand ? First I launch the interface thread from Caml with
Thread.create and the interface thread calls Glut.main_loop which never 
ends (except when the program terminates). This main loop call some Caml 
functions.

The interface thread (which is the main thread) is affected a lot may be 
because the main_loop sleep while retaining a mutex blocking the 
computing thread. This is hat you mean ?

> Dave

-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Caml-list] Scheduling thread problem kernel 2.6

[Daniel Bünzli]

Le 14 avr. 04, à 07:58, Christophe Raffalli a écrit :

> I do not understand ? First I launch the interface thread from Caml 
> with
> Thread.create and the interface thread calls Glut.main_loop which 
> never ends (except when the program terminates). This main loop call 
> some Caml functions.

My understanding is that the Glut.main_loop stub should be something 
like

#include <caml/signals.h>

CAMLprim value ocaml_glutMainLoop(value v)
{
	enter_blocking_section();
	glutMainLoop();
	leave_blocking_section(); /* This will in fact never be called */
	return Val_unit;
}

enter_blocking_section() releases the master mutex that ensures single 
threaded execution of caml code and allows other caml threads to 
proceed. Now each callback calling back from C into caml should 
reacquire the master lock to avoid concurrent execution of caml code. 
To do so callbacks from C into caml should be wrapped as follows,

...
leave_blocking_section();
callback(*caml_named_value("myfun"), Val_unit);
enter_blocking_section();
...

See also this message

<http://caml.inria.fr/archives/200106/msg00199.html>

Hope that helps,

Daniel
-------------------
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

Re: [Caml-list] Scheduling thread problem kernel 2.6

[Christophe Raffalli]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

Daniel Bünzli wrote:
> 
> Le 14 avr. 04, à 07:58, Christophe Raffalli a écrit :
> 
>> I do not understand ? First I launch the interface thread from Caml with
>> Thread.create and the interface thread calls Glut.main_loop which 
>> never ends (except when the program terminates). This main loop call 
>> some Caml functions.
> 
> 
> My understanding is that the Glut.main_loop stub should be something like
> 
> #include <caml/signals.h>
> 
> CAMLprim value ocaml_glutMainLoop(value v)
> {
>     enter_blocking_section();
>     glutMainLoop();
>     leave_blocking_section(); /* This will in fact never be called */
>     return Val_unit;
> }

No it does not enter a blocking section (I checked the code of 
LablGlut). Moreover, if it was the case, Glsurf would never have worked 
correcdtly under kernel 2.4. You do not need in general to enter a 
blocking section when calling C. you only need that if you call some 
specific Caml function from C (if I remember well)



-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
---------------------------------------------
IMPORTANT: this mail is signed using PGP/MIME
At least Enigmail/Mozilla, mutt or evolution
can check this signature
---------------------------------------------

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Caml-list] Scheduling thread problem kernel 2.6

[Daniel Bünzli]

	
Le 14 avr. 04, à 11:21, Christophe Raffalli a écrit :

> You do not need in general to enter a blocking section when calling C. 
> you only need that if you call some specific Caml function from C (if 
> I remember well)

True, this message [1] confirms it (point 6) and since callbacks are 
not executed concurrently by glut there is no need to serialize them 
with enter/leave_block_section(). Apparently [2] 
enter/leave_blocking_section() are mainly used to allow the execution 
of signal callbacks during execution of long running C code that 
doesn't interact with caml code (this means that if I use the lablglut 
bindings, my signal callbacks will never be executed, so I think it 
would be better to use enter/leave_blocking_section() in the bindings 
as depicted in my previous message).

Regarding your problem, maybe glutMainLoop() is doing busy waiting. You 
can try to look into the code [3], glutMainLoop() is implemented in 
file lib/glut/glut_event.c. However this wouldn't explain the fact that 
your program was running well in another version of your system.

Daniel

[1] <http://caml.inria.fr/archives/200404/msg00258.html>
[2] <http://caml.inria.fr/archives/200304/msg00243.html>
[3] <http://www.opengl.org/resources/libraries/glut/glut37.zip>
-------------------
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