On 31 May 2013 11:26, Norbert Hartl <[email protected]> wrote: > > Am 27.05.2013 um 10:17 schrieb [email protected]: > > I was looking at the output of "top" for while and Pharo was trusting the > top spot indeed. > > Well, I'll look at all that this evening and give back the impressions. > > I want to run several instances of Pharo on the box and it will for sure add > up. Say, 20 x 2% gives an awful lot. > > What is the use of having 20 idle images on one server? :) I think you > can't easily say that it always adds on top. If your image is running at > 100% the 2% off even if fully countable wouldn't be that much. But > nevertheless it is a valid point and I cannot see pharo becomes more modern > by stop polling in the mid-term future. > Anyway I played a little bit with the tweaks and there are things that make > me wonder. I raised the limit for server mode but didn't get much benefit. > Having a cycle pause of 100ms in serverMode and stopping the ui process > still gave me a 1% CPU usage which is really a lot. Does anyone know > in-depth what an image is doing? How to investigate? Maybe there are a lot > of native polling things involved, too? > I need to dig deeper. >
each ms, a heartbeat thread wakes up and triggers interrupt processing. this is equivalent to polling each 1ms just yesterday we discussed this.. the problem is how to avoid interrupt processing each ms and support green threading at same time. i know that hardware given plenty of opportunities to do that.. but the problem is that most of it available only in privileged mode. i hate to see that: hardware allows much better scheduling handling, but we're doomed to use ineffective scheme, because of OS limitations. > Norbert > > Phil > -- Best regards, Igor Stasenko.
