Miguel Figueiredo wrote:I spent a few hours running the -ck2 patch, and I didn't see any numbers like yours. What I did see is going up with my previous results as http://www.tmr.com/~davidsen/sched_smooth_04.html. While there were still some minor pauses in glxgears with my test, performance was very similar to the sd-0.48 results. And I did try watching video with high load, without problems. Only when I run a lot of other screen-changing processes can I see pauses in the display.No, I haven't made it clear. A known number (default four) of xterms are started, each of which calculates random numbers and prints them, using much CPU time and causing a lot of scrolling. At the same time glxgears is running, and the smoothness (or not) is observed manually. The script records raw data on the number of frames per second and the number of random numbers calculated by each shell. Since these are FAIR schedulers, the variance between the scripts, and between multiple samples from glxgears is of interest. To avoid startup effects the glxgears value from the first sample is reported separately and not included in the statistics.
Hi Bill,
if i've understood correctly the script runs glxgears for 43 seconds and in that time generates random numbers in a random number of times (processes, fork and forget), is that it?
I looked at your results, and they are disturbing to say the least, it appears that using the ck2 scheduler glxgears stopped for all practical purposes. You don't have quite the latest glitch1, the new one runs longer and allows reruns to get several datasets, but the results still show very slow gears and a large difference between the work done by the four shells. That's not a good result, how did the system feel?You find the data, for 2.6.21-{cfs-v13, ck2} in http://www.debianpt.org/~elmig/pool/kernel/20070522/Thank you, these results are very surprising, and I would not expect the system to be pleasing the use under load, based on this.
Here's the funny part...It's really the relative work done by identical processes, hopefully they are all nearly the same, magnitude is interesting but related to responsiveness rather than fairness.
Lets call:
a) to "random number of processes run while glxgears is running", gl_fairloops file
b) to "generated frames while running a burst of processes" aka "massive and uknown amount of operations in one process", gl_gears fileWell, top or ps will give you a good idea of processing, but it tried to use all of one CPU if allowed. Again, similarity of samples reflects fairness and magnitude reflects work done.
kernel 2.6.21-cfs-v13 2.6.21-ck2Everyone seems to like ck2, this makes it look as if the video display would be really pretty unusable. While sd-0.48 does show an occasional video glitch when watching video under heavy load, it's annoying rather than unusable.
a) 194464 254669 b) 54159 124
Your subjective impressions would be helpful, and you may find that the package in the www.tmr.com/~public/source is slightly easier to use and gives more stable results. The documentation suggests the way to take samples (the way I did it) but if you feel more or longer samples would help it is tunable.I'll include the -ck2 patch in my testing on other hardware.
I added Con to the cc list, he may have comments or suggestions (against the current versions, please). Or he may feel that video combined with other heavy screen updating is unrealistic or not his chosen load. I'm told the load is similar to games which use threads and do lots of independent action, if that's a reference.