Performance monitors, task managers, etc?

[fireshadow4126]

Hello,

I'm just wondering (I'm nowhere near the stage at which I would be able to implement this), but how do task managers/system monitors like those of Windows 7 and Ubuntu (my main host operating systems) measure the percentage of the CPU that a process is using, and how do they measure this number at a constant interval?

Thanks in advance!

[gravaera]

Yo:

I haven't yet got this far in my project, but I have cursorily thought about how to implement such a feature. A process's "percentage of available CPU resource used" can be measured really only by (1) how often it is placed onto a CPU, and (2) how long it runs on said CPUs for. My ideas aren't fully fleshed out, given that this is (imho) userspace work mostly, but:

AFAICT the kernel itself has no use for such information: kernel should schedule tasks according to the parameters given to it in that task's scheduling and affinity requirements. If a task is high priority, then the kernel shouldn't try to implement "fairness" by downsizing its runtime for example. It simply is high priority, and should be run as often as it is to be run. For non-high-priority threads, the kernel may possibly modify the timeslice-duration of a thread, or lower or raise its priority based on various criteria;

For example, if the user has indicated (however that would be done for the example kernel) that the kernel should favour interactive response time, the kernel would then possibly prefer CPU-bound tasks to I/O-bound tasks? Or if the kernel has been placed into "power saving" mode, it may favour I/O bound tasks over CPU bound tasks; those choices would be highly situational, etc. But all of these choices do not need any real form of taking stock of the CPU usage of tasks over a period of time; so I think the "CPU usage" feature is actually done, or could be done entirely in userspace by the Task manager program.

First of all, the "Task manager" only refreshes the stats of the running processes every 2-5 seconds, or some other interval, so the amount of system load caused by constantly refreshing is probably low, and the task manager will most likely be sleeping 90% of the time it's operating. My take on it is to have the kernel implement a syscall interface for querying process control blocks; The "task manager" can call this every few seconds, then compare the current process stats against the previous ones, and begin to generate a "usage" profile.

I suppose the only thing the kernel would need to do is to take record of the "number of timeslices" each process was given each second. That's reasonably simple, sort of. If a kernel has a 500Hz timer, then every 500 ticks would mean 1 second has passed. You can have the kernel increment a looping counter on each tick, and when it hits 500, you add 1 to a "number of seconds gone by" counter. Every time a task is pulled the kernel increments its "number of timeslices for the current second", or if the looping counter had been reset, it would just restart counting that thread's "number of timeslices for the current second" again from 0. A lot of the counter stuff can be tied to the kernel's timer subsystem easily also.

The task manager would just quickly round up those statistics with some syscalls, display the results from the syscalls as "current usage", then compare prior results against current results for "average usage", then go back to sleep (sleep(NUMBER_OF_SECONDS)). The syscalls are completely non-I/O bound, so they'd run pretty fast...memcpy() the stats to a buffer for the userspace task manager. Then the task manager just does some fast CPU-bound calculations, and then updates its window to redraw the graphs. It'll be useful to see what edification other folks can add to this, I'd be appreciative of comments and discussion.

--Peace out
gravaera