Re: Mirage/kFreeBSD on GitHub

[PALI Gabor Janos <pgj@xxxxxxx>]

On Sat, Aug 04, 2012 at 08:17:49AM -0400, Robert N. M. Watson wrote:
> On debugging: is this a multi-CPU system or a single-CPU system?

This is a single-CPU virtual machine.  But I can reconfigure it to have
2 processors.


> Are you able to break into the debugger using the break sequence?

No, I have not tried it yet, but I will.


> 1. This is a single-CPU system and something in the kernel (OCaml?) is 
> running in a loop, preventing userspace from running.

I tried to solve this problem by launching the OCaml execution on a separate
kernel thread.  You can find my attempt to do this here:

https://github.com/pgj/mirage-kfreebsd/blob/master/packages/mirage-platform/runtime/kernel/kmod.c

I set the lowest priority possible to this thread to enable the userspace to
continue running while the OCaml program may not finished its execution.  And
this seems to work well so far.


> If you use a multi-CPU system you might find userspace is able to run on 
> another CPU, and a tool like top (using -SH or similar) spots the problem.

No, I could not launch top(1) on the other terminal with even 2 processors.
However, the situation has improved a little bit as I was at least able to
type something and have it processed by the shell.


> Break into the debugger, [..] and use WITNESS's "show alllocks" to see if 
> there's an obvious candidate for 2.

Okay, thanks for the hint, I will give it a try.


> Also, if you're kicking off your code with sysctl, is there some mutual 
> exclusion or other mechanism to deal with the possibility that more than once 
> instance of the sysctl might get started at once? (e.g., return EBUSY in 
> thread two if thread one is already running the OCaml code).

Yes, there is a simple variable (mirage_kthread_done) in the file above that
flags the thread responsible for running the OCaml execution still working.

Note that I have successfully run OCaml programs taking longer time, e.g.
calculating the 42nd element of the Fibonacci series, while the rest of the
system remain responsive.

Thus I am willing to think that this effect is related to the memory
allocation and/or the operation of the garbage collector.