[ENH] CPU time for Processes.
John M McIntosh
johnmci at smalltalkconsulting.com
Fri Mar 9 03:49:42 UTC 2001
I'm tossing this out to the Squeak list for comment. Perhaps it can
assist in debugging where the time goes.
Today at a client we watched a set of processes run in another
dialect of Smalltalk and wondered where the CPU time was going. It's
hard to track isn't it? Oh, we used TOP and the like to watch the
other Unix processes and it occurred to me all the Operating system
(Solaris) was doing was tracking CPU dispatch time for the Unix
process and giving those milliseconds values to us to admire. So why
can't we know how much time a particular process runs in the VM?
Smalltalk is just an OS right, we need to collect some metrics. Well
we can, just a few changes are required.
I spent a few hours this evening looking at how to solve this
problem. You see although much of the process scheduler is exposed
most of it really lives in the VM. So you can't just add code to
Process suspend and resume...
First I added new instance vars to Process, startTime, and
runDuration which track when a process starts based on the
millisecond clock, and duration which is calculated from the
startTime and the time the process is stopped when another is
started. This duration accumulates as an integer.
Now in Interpreter>>transferTo: aProc it suspends the current
process and starts the new process running. I *think* this is the
only place where a process switch occurs. IE for Jitter this seems
the only place where we notify the compiler that the process is
changing. So we just look at the millisecond clock, look at startTime
which should be in the past, calculate the diff and add to
runDuration. For the about to be started process we store the current
time and keep going.
Note we could store the time we stopped the old process to get the
suspend time, but I'll let the crowd decide if this is useful.
Perhaps you might want it to boost processes that have been sleeping
too long?
So now I can track how many milliseconds a Smalltalk process has been
dispatch for the hosting OS CPU to work with.
To get this to work you need a new VM!!!! built with this patch. Also
you might need the latest VM with the class reshaping patch to keep
the VM from crashing when it reshapes the Process class. (For the mac
this is 3.0.9, which isn't out the door yet, just try doing uploads
etc at 14400 baud).
So file this in, hope it doesn't crash your image, and see if you can
get a new VM. If you need a mac VM (3.0.10) to test with let me know.
Note you get a notifier berating you that changing Process isn't a
good idea, just keep going.
What else... Mmm I altered ProcessBrowser a bit to print the value of
runDuration, via the Process print methods. But we need a startup
method to reset the startTime and runDurations when an image
restarts. I'm sure we could calculate % of CPU used per update
interval and the like with a little bit of code eh?. I'll leave some
of the details to others, just getting the numbers is enough for this
evening.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CaptureProcessTimeJMM.4.cs
Type: application/mac-binhex40
Size: 4586 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010308/3efd2d02/CaptureProcessTimeJMM.4.hqx
-------------- next part --------------
--
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
===========================================================================
More information about the Squeak-dev
mailing list
|