Smalltalk › Squeak › Squeak VM

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

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

Eliot Miranda-2

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

On Thu, Nov 25, 2010 at 8:25 PM, John M McIntosh <[hidden email]> wrote:

On 2010-11-23, at 1:23 AM, Henrik Sperre Johansen wrote:

> On 22.11.2010 22:08, Guido Stepken wrote:
>> Need additional:
>>
>> isOnMouseOverEvent
>> isMouseGestureEvent
>> isTouchGestureEvent
> You could try checking out how the iOS code does support for complex events.
> It's of course somewhat apple-specific, but hey, would be nice to have the same image-side representation and handling of touch-based events if possible.

Apple is very very notification &event callback oriented in their iOS platform. It sleeps until you touch, then you get a touch event, you process and go back to sleep. Heck if your startup time takes too many seconds Apple nails you.

For Squeak on iOS I take the touch data place on a queue and signals the event semaphore. When the squeak image polls for the event we
turn the touch data into a complex event and pass it back, then is processed by the Smalltalk code to turn into synthetic mouse events. (or something).

For keyboard entry, we take the key input data and turn into synthetic keystroke events, and again signal the semaphore and put on a queue for later when
the Smalltalk code wakes up and calls getnextevent to see what's up.

I'm not sure if anyone mentioned the other issue is that the polling loop also deals with doing the morphic redrawing so it runs a cycle of doing I think it is
50 iterations a second.

For WikiServer which doesn't show a squeak UI I could cut that back to doing a cycle every second or so.

Oh and yet one more thing, the clock tick is yet another issue, some platforms assume they can run an interrupt 1000 a second (or more) to ensure the VM is responsive to Delay being correctly woken up to the microsecond. "PS here I am over simplify the issue & complexity of the issue" but on underpowered hardware the issues of how ioRelinquishProcessorForMicroseconds and the millisecond timer work become messy issues in relationship to CPU usage.

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 <[hidden email]> Twitter: squeaker68882
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================

johnmci

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

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 <[hidden email]> Twitter: squeaker68882

Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com

===========================================================================

Igor Stasenko

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

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.

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.

On 27 November 2010 00:40, John M McIntosh
<[hidden email]> 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 <[hidden email]> Twitter: squeaker68882
> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
>

--
Best regards,
Igor Stasenko AKA sig.

Eliot Miranda-2

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

On Fri, Nov 26, 2010 at 6:22 PM, Igor Stasenko <[hidden email]> 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

<[hidden email]> 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 <[hidden email]> Twitter: squeaker68882
> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>
>

--
Best regards,
Igor Stasenko AKA sig.

Levente Uzonyi-2

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

On Tue, 11 Jan 2011, Eliot Miranda wrote:

(Pine can't quote your mail, sorry.)

"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."

What about keeping the priority of the heartbeat thread at user-level and
decreasing the other VM threads' priority slighly?

Levente

Eliot Miranda-2

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

2011/1/11 Levente Uzonyi <[hidden email]>

On Tue, 11 Jan 2011, Eliot Miranda wrote:

(Pine can't quote your mail, sorry.)

"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."

What about keeping the priority of the heartbeat thread at user-level and decreasing the other VM threads' priority slighly?

Linux doesn't allow more than /one/ thread priority for threads in a user-level process. So one /can't/ have multiple priorities. All threads run at the same priority. This is a horrible bug in the linux pthreads implementation but there it is.

best

Eliot

Levente

Nicolas Cellier

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

2011/1/11 Eliot Miranda <[hidden email]>:

>
>
>
> 2011/1/11 Levente Uzonyi <[hidden email]>
>>
>>
>> On Tue, 11 Jan 2011, Eliot Miranda wrote:
>>
>> (Pine can't quote your mail, sorry.)
>>
>> "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."
>>
>> What about keeping the priority of the heartbeat thread at user-level and decreasing the other VM threads' priority slighly?
>
> Linux doesn't allow more than /one/ thread priority for threads in a user-level process. So one /can't/ have multiple priorities. All threads run at the same priority. This is a horrible bug in the linux pthreads implementation but there it is.
> best
> Eliot

Superficial googling "setting linux pthread priority" gives me this
thread (java)
http://kerneltrap.org/node/6080

It seems that there are different scheduling policies in linux 2.6
kernel, realTime, and non real time (traditional unix time sharing).
It seems that only real time threads can have their priority set.

man sched_setscheduler

After man 7 pthreads, it appears that the scheduling policy would be
different for each thread.

However, the functionalities of interest are provided by the NPTL
(Native POSIX Threads Library).
The older LinuxThreads implementation might not implement POSIX.1
complying threads.

So, some linux might work, for example, in my fresh mandriva 2010.2
x86-32, I test
$ getconf GNU_LIBPTHREAD_VERSION
NPTL 2.11.1

To be confirmed...

Nicolas

>>
>> Levente
>
>
>

Eliot Miranda-2

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

On Tue, Jan 11, 2011 at 12:26 PM, Nicolas Cellier <[hidden email]> wrote:

2011/1/11 Eliot Miranda <[hidden email]>:

>
>
>
> 2011/1/11 Levente Uzonyi <[hidden email]>
>>
>>
>> On Tue, 11 Jan 2011, Eliot Miranda wrote:
>>
>> (Pine can't quote your mail, sorry.)
>>
>> "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."
>>
>> What about keeping the priority of the heartbeat thread at user-level and decreasing the other VM threads' priority slighly?
>
> Linux doesn't allow more than /one/ thread priority for threads in a user-level process. So one /can't/ have multiple priorities. All threads run at the same priority. This is a horrible bug in the linux pthreads implementation but there it is.
> best
> Eliot

Superficial googling "setting linux pthread priority" gives me this
thread (java)
http://kerneltrap.org/node/6080

It seems that there are different scheduling policies in linux 2.6
kernel, realTime, and non real time (traditional unix time sharing).
It seems that only real time threads can have their priority set.

man sched_setscheduler

After man 7 pthreads, it appears that the scheduling policy would be
different for each thread.

However, the functionalities of interest are provided by the NPTL
(Native POSIX Threads Library).
The older LinuxThreads implementation might not implement POSIX.1
complying threads.

So, some linux might work, for example, in my fresh mandriva 2010.2
x86-32, I test
$ getconf GNU_LIBPTHREAD_VERSION
NPTL 2.11.1

To be confirmed...

You don't have to confirm this. We have confirmed this at length over the past year at Teleplace. realtime scheduling is /not allowed/ in non-super-user processes. So unless the Squeak VM is to be installed setuid and run as root it, like all other non-setuid programs on linux, must make do with a /single/ thread priority.

I have a _few_ test programs that you're welcome to try out if you really don't believe me :)

best

Eliot

Nicolas

>>
>> Levente
>
>
>

Nicolas Cellier

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

2011/1/11 Eliot Miranda <[hidden email]>:

>
>
>
> On Tue, Jan 11, 2011 at 12:26 PM, Nicolas Cellier <[hidden email]> wrote:
>>
>> 2011/1/11 Eliot Miranda <[hidden email]>:
>> >
>> >
>> >
>> > 2011/1/11 Levente Uzonyi <[hidden email]>
>> >>
>> >>
>> >> On Tue, 11 Jan 2011, Eliot Miranda wrote:
>> >>
>> >> (Pine can't quote your mail, sorry.)
>> >>
>> >> "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."
>> >>
>> >> What about keeping the priority of the heartbeat thread at user-level and decreasing the other VM threads' priority slighly?
>> >
>> > Linux doesn't allow more than /one/ thread priority for threads in a user-level process. So one /can't/ have multiple priorities. All threads run at the same priority. This is a horrible bug in the linux pthreads implementation but there it is.
>> > best
>> > Eliot
>>
>> Superficial googling "setting linux pthread priority" gives me this
>> thread (java)
>> http://kerneltrap.org/node/6080
>>
>> It seems that there are different scheduling policies in linux 2.6
>> kernel, realTime, and non real time (traditional unix time sharing).
>> It seems that only real time threads can have their priority set.
>>
>> man sched_setscheduler
>>
>> After man 7 pthreads, it appears that the scheduling policy would be
>> different for each thread.
>>
>> However, the functionalities of interest are provided by the NPTL
>> (Native POSIX Threads Library).
>> The older LinuxThreads implementation might not implement POSIX.1
>> complying threads.
>>
>> So, some linux might work, for example, in my fresh mandriva 2010.2
>> x86-32, I test
>> $ getconf GNU_LIBPTHREAD_VERSION
>> NPTL 2.11.1
>>
>> To be confirmed...
>
> You don't have to confirm this. We have confirmed this at length over the past year at Teleplace. realtime scheduling is /not allowed/ in non-super-user processes. So unless the Squeak VM is to be installed setuid and run as root it, like all other non-setuid programs on linux, must make do with a /single/ thread priority.
> I have a _few_ test programs that you're welcome to try out if you really don't believe me :)
> best
> Eliot

Hmm yes, i was just browsing
man 7 capabilities
very defensive...

Nicolas

>>
>> Nicolas
>>
>> >>
>> >> Levente
>> >
>> >
>> >
>
>
>

Igor Stasenko

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

In reply to this post by Eliot Miranda-2

On 11 January 2011 20:23, Eliot Miranda <[hidden email]> wrote:

So, why not use signals & POSIX timer [1] for same purpose?
Or do signals having other issues which even worse than using heartbeat process?

[1] http://www.kernel.org/doc/man-pages/online/pages/man2/timer_create.2.html

> best
> Eliot
>>
>> Levente
>
>
>

--
Best regards,
Igor Stasenko AKA sig.

Eliot Miranda-2

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

On Tue, Jan 11, 2011 at 1:08 PM, Igor Stasenko <[hidden email]> wrote:

On 11 January 2011 20:23, Eliot Miranda <[hidden email]> wrote:
>
>
>
> 2011/1/11 Levente Uzonyi <[hidden email]>
>>
>>
>> On Tue, 11 Jan 2011, Eliot Miranda wrote:
>>
>> (Pine can't quote your mail, sorry.)
>>
>> "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."
>>
>> What about keeping the priority of the heartbeat thread at user-level and decreasing the other VM threads' priority slighly?
>
> Linux doesn't allow more than /one/ thread priority for threads in a user-level process. So one /can't/ have multiple priorities. All threads run at the same priority. This is a horrible bug in the linux pthreads implementation but there it is.

So, why not use signals & POSIX timer [1] for same purpose?
Or do signals having other issues which even worse than using heartbeat process?

What would the benefit of using timer_create (which looks to be linux-specific) instead of setitimer? Both would deliver their pulse via signals, no? You're very welcome to try this and see whether e.g. the use of SIGEV_THREAD_ID or SIGEV_THREAD works better than the heartbeat's use of sigaction. I can give you some tests to run to ensure the VM's heartbeat is working correctly. It is essentially

| start stop |

start := Time millisecondClockValue.

stop := start + 1000.

[Time millisecondClockValue <= stop] whileTrue

This will lock-up a threaded heartbeat on linux since the hard loop doesn't allow the heartbeat thread to run if the heartbeat thread's priority is the same as the VMs. So this may break SIGEV_THREAD if the implementation is really based on threads.

best

Eliot

[1] http://www.kernel.org/doc/man-pages/online/pages/man2/timer_create.2.html

> best
> Eliot
>>
>> Levente
>
>
>

--

Best regards,
Igor Stasenko AKA sig.