Re: How to preempt a thread?

[David Scott <scott.dj@xxxxxxxxx>]

Hi,

On Tue, Nov 5, 2013 at 7:33 PM, Goswin von Brederlow <goswin-v-b@xxxxxx> wrote:

Hi,

I'm trying to run ocaml bare-metal on a RaspberryPi. Since the RPi
only has an ARMv6 cpu it has no virtualization extension and running
mirage under xen is not an option. :( But I'm basically doing the same
as mirage I was hopeing I could borrow some knowledge from you.

My question concerns threading.

1) How have you implemented this at all in mirage?

Did you rewrite the thread module or provide the pthread api/abi so
the existing module works?

Mirage only uses co-operative threads via Lwt. When the Lwt scheduler has run out of "threads" it calls a hypercall ("SCHEDOP_block") which takes the vCPU offline. When an interrupt fires the vCPU jumps into a C callback, which would normally do some work in a regular OS, but in Mirage it does nothing. When the callback returns we re-run the main loop. The main loop checks which interrupts have fired (this information is in a shared memory page) and signals any blocking lwt threads. The main loop runs the Lwt scheduler, and eventually blocks again.

This demonstrably works: we've got co-operative drivers, HTTP implementations etc. However there is no pre-emption so we can enter into infinite loops if we're not careful. The code tends to be fairly "threaded" (lots of Lwt.binds) so there are lots of opportunities for the Lwt scheduler.

At some point we ought to check out the multi-runtime patches so we can fire up multiple OCamls, one per vCPU. Perhaps it would be useful to implement some kind of watchdog which would reboot the OCaml runtime if it does get stuck.

2) CPU hogging

My understanding is that normal native code sets a timer in the
threading module. When the timer expires it plays with the minor heap
limit to trick the GC into running on the next allocation and hooks
the scheduling into that. So it is not truely preemptive and a thread
that doesn't do any allocations will hog the CPU.

Have you addressed this problem, if at all, in mirage?

Nope :/

 

MfG
        Goswin

PS: If I get enough hardware drivers working I might work on merging
with mirage, getting it to boot on bare-metal arms without xen.

This would indeed be very cool. IIRC the RPi opengl driver for Linux is just a shim which marshals opengl over shared memory to be interpreted by the broadcom firmware. If this is true then we could even get 3D on the console (eventually). However I'm sure it's best to walk before we try running :)

Cheers,

Dave