[Vm-dev] linux thread priorities

[Eliot Miranda]

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

Damn right :)  But it is only called at a maximum of once every millisecond
or two (I think 2ms is an adequate delay resolution). On current machines
one can't run the heartbeat at much more than 100 usecs because thats how
long it takes each heartbeat (which does a thread switch, updates the clock
and sets some flags).

Of course Cog is grinding out those bytecodes a lot faster than the normal
Squeak VM so a 500Hz heartbeat is reasonably affordable :)

Perhaps I should explain how this works in Cog.  Cog does not call
checkForInterrupts in normal processing of bytecodes.  Instead it checks the
stack limit on every frame-building send (i.e. not quick methods that answer
constants & inst vars, and not primitives that succeed).  It has to check
the stack limit because the VM runs Smalltalk code on small stack pages (~64
pages, 4k bytes each), "paging out" a stack page worth of frames to heap
contexts when there is no free page available.  When stack overflow occurs
it breaks out of machine code to handle the switch from the current stack
page to a new one, and as part of that processing it checks for events.  The
heartbeat works by setting the stack limit to a value that will cause all
stack limit checks to fail (this being 16rFFFFFFFF because stacks grow
down).

The HotSpot Java VM uses a similar technique, but their stacks are not
organized as pages (because Java doesn't have contexts one can map the java
stack to a native thread stack quite easily, whereas the paged organization
works well for marrying contexts and stack frames).  On frame build they
write to a location on a guard page.  Since there is no load dependency for
a write the write doesn't stall the processor.  When they want to break out
of Java machine code they remove write permission from the page and handle
the protection violation exception.  Of course this only works on systems
where changing a page's protection is very cheap compared to the breakout
frequency.  It wouldn't work for a 1Khz beat; you'd spend all of your time
twiddling page protections.  But a neat technique all the same.

best
Eliot

>
>
> On 2010-02-03, at 6:01 PM, Eliot Miranda wrote:
>
> I've been trying to get our sound framework going on linux and have got
> stuck.  I wondered whether anyone has any experience getting round this
> problem on linux.  It is complicated so excuse the lengthy explanation.
>
> Our sound processing depends on a high-prirority thread running for a short
> time every 20 milliseconds to push data through the sound processing paths
> (microphone recording, OpenAL for spatialization, and so on).  On linux this
> approach is not immediately applicable because (*)
>
>
> --
> ===========================================================================
> John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:
>  squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100204/7abb47c3/attachment.htm