[Vm-dev] linux thread priorities

[Eliot Miranda]

Replying to mine and John's suggestion of moving the pump to the VM's check
event loop.

On Wed, Feb 3, 2010 at 9:31 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

> [snip]
> I think one interim solution to explore is to run the sound pump from the
> VM thread in the VM's check for events code.  In the Cog VMs a 1KHz
> heartbeat updates the wall clock and causes the VM to break out of native
> code and check for events (ideally the heartbeat is a separate thread).  An
> mentioned, on linux the heartbeat is a software signal from an interval
> timer.  The software interrupt serves also to interrupt any system calls
> (e.g. in relinquishProcessorForMilliseconds).  I can extend the heartbeat to
> set a flag saying "run the sound pump" which will be checked by the VM when
> checking for events and it will invoke the sound pump code.  The problem
> here is that any long-running activities that aren't interruptable by the
> software interrupt (OpenGL rendering?) will delay the sound pump.  So this
> is either doomed to failure or might just work depending on those other
> activities.  Comments?  Try it, waste of time?
>

Obvious really, but this can't work.  See below.

On Wed, Feb 3, 2010 at 9:44 PM, John M McIntosh <
johnmci at smalltalkconsulting.com> wrote:

>
> Well mmm doesn't the checkForInterrupts code get called every 1 millisecond
> (or there about?)
> Can't you add something there to ensure your sound logic doesn't starve.
>
> Hint if checkForInterrupts is not being called every ms or so how do you
> ensure delay accuracy is to a ms boundary?
>

There is no guarantee that checkForInterrupts is being called
every millisecond.  There is only a guarantee that the VM will be asked
to checkForInterrupts every millisecond.  It will actually check as soon as
it next checks.  So if it is in a long-running primitive, or more
importantly a full garbage collection it will check when this has finished.
 The GC pauses are the killer.  For us every now and then there is a >100ms
pause for GC and so the sound pump will occasionally be starved.

Essentially the sound pump has to run as an interrupt or in another thread.

I am going to try one horrible hack.  Right now the deadlock I'm seeing is
in the sound pump's logging code that calls ctime_r to grab an ascii string
of the local time to timestamp log entries.  The VM can keep a copy of
ctime_r's result and update it synchronously every second or so, instead of
calling ctime_r on every log entry.  This won't remove the possibility of
lock-up due to other library calls, but it may reduce the probability low
enough that our alpha demo will work sufficiently and give us time to work
on a proper solution (i.e. investigating Bert's direction to improved linux
schedulers) after the demo.


> next hint if checkForInterrupts is being called 10 times a millisecond then
> isn't that wasteful, should you be grinding smalltalk bytecodes or assembler
> instructions there of?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100204/eaee3927/attachment.htm