[Vm-dev] Unix heartbeat thread vs itimer

[Ben Coman]

On Tue, Mar 21, 2017 at 6:18 AM, Holger Freyther <holger at freyther.de> wrote:
>
>
>
> > On 20 Mar 2017, at 17:43, Ben Coman <btc at openinworld.com> wrote:
>
> > > On Sat, Jan 7, 2017 at 3:23 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> > > This is because its job is to cause Smalltalk code to break out at regular intervals to check for events.  If the Smalltalk code is compute-intensive then it will prevent the heartbeat thread from running unless the heartbeat thread is running at a higher priority, and so it will be impossible to receive input keys, etc. (Note that if event collection was in a separate thread it would suffer the same issue; compute intensive code would block the event collection thread unless it was running at higher priority).
> >
>
> > Perhaps the heatbeat thread needed it static priority managed manually for with Linux 2.4,
> > but maybe that is not required in 2.6 ??
>
> The "flaw" in this experiment is that number of runnable threads is most likely smaller or equal to the number of physical processors. You can use cpu affinity to bind your application to a single CPU and see the delay. I think the "jitter" will likely be higher.
>

Great insight.  I'll try two things: cpu affinity & loading the other
cpus with my previous fibinachi experiment.

Keep in mind though that most modern desktop systems are overpowered,
usual peaking loads less than 40% unless something goes haywire.  And
smaller systems like the Pi seem to default to operating as root, so
can bump the heatbeat priority.

cheers -ben