[Vm-dev] Re: [Pharo-project] Waste of CPU Power by polling events?

[Eliot Miranda]

On Fri, Nov 26, 2010 at 6:22 PM, Igor Stasenko <siguctua at gmail.com> wrote:

> In Hydra, i merged the heartbeat and delay timeout logic into single
> routine, which were running in high-priority thread.
> It simply picks the nearest possible time to wait (sleep) - either
> heartbeat cycle delay, or scheduled Delay timeout,
> then signals VM to interrupt and handle delay or do regular event
> processing using ioHandleEvents().
>
> What is good in Windows, that there are special event mask for
> WaitForMultipleEvents() function,
> which could put a thread in wait till keyboard/mouse input available.
> In that way, on Windows, VM could avoid frequent interrupts to for
> polling events, and instead use waiting thread(s),
> and interrupt only if some event signaled.
>

Yes, that's what I did in the VW VM.   WaitForMultipleEvents also takes a
timeout so one can wait until an event or the next delay with a single call.


> FreeBSD also introduced a kernel events, so instead of polling, one
> could simply wait for I/O activity (like file, socket etc). Not sure
> about mouse/keyboard input. I'm not sure, but think i heard linux
> kernel also integrated that recently.
>

The problem with linux is that the pthreads implementation doesn't allow a
normal user-level process to create high-priroity threads so that as soon as
the Vm starts to spin doing some computation the heartbeat thread is
shut-out and if the spinning computation only interrupted when a delay
expires it'll never get interrupted because it is blocking the very thread
that would signal the delay.  So until linux's pthreads implementation
supports multiple priorities we're stuck with hacks like the interval timer
based itimer in the linux Cog VMs.


>
> On 27 November 2010 00:40, John M McIntosh
> <johnmci at smalltalkconsulting.com> wrote:
> >
> > Eliot, I had looked at turn off the heartbeat when we did the nanosleep,
> then turned it back on.  The problem was actually trying to figure out if
> > it did any good since the cost of  pausing/restarting the heartbeat task
> was high. I think first we have to quantify the costs. This is difficult to
> do on desktop
> > machines since they are so fast, so I was working with an iPod touch
> which is 1000x (wild guess number) times slower.
> > I'm also unsure of the pattern for when
> the ioRelinquishProcessorForMicroseconds is called and for how long. Further
> to that we do attempt to calculate the next wake up time, but sometime it's
> in the past, so why is ioRelinquishProcessorForMicroseconds being called?
> Even if we sleep then how long and what wakes us up early?
> > On 2010-11-26, at 8:39 AM, Eliot Miranda wrote:
> >
> > Yes, we need to change this, but I think one has to change the background
> process and/or nothing to run behavior.  In the VW VM the VM disables the
> heartbeat and enters some blocking call when there's nothing to do.  Squeak
> runs the background process which calls a primitive that sleeps for a short
> time.  The former is much better.  If a delay is active as the VM does to
> sleep it schedules a wakeup event or supplies a timeout so that it blocks
> until input is available or the next delay.
> > We could still keep the background process and do something similar to
> VW, disabling the heartbeat until after the relinquish, and factoring the
> delay into the relinquish timeout.
> > Also the heartbeat already has facilities to change its frequency, so one
> could modify things to slow down the heartbeat, again ensuring that it ticks
> before the next delay expiry.
> > What approach (not necessarily from the above) appeals to you John?
> > best
> > Eliot
> >
> > --
> >
> ===========================================================================
> > John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:
>  squeaker68882
> > Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> >
> ===========================================================================
> >
> >
> >
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110111/c024b3b2/attachment.htm