Re: Sched - graphic smoothness under load - cfs-v13 sd-0.48

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I was unable to reproduce the numbers Miguel generated, comments below. The -ck2 patch seems to run nicely, although the memory repopulation from swap would be most useful on system which have a lot of memory pressure.

Bill Davidsen wrote:
Miguel Figueiredo wrote:

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?

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.

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

Lets call:

a) to "random number of processes run while glxgears is running", gl_fairloops file

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.
b) to "generated frames while running a burst of processes" aka "massive and uknown amount of operations in one process", gl_gears file

Well, 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-ck2
a)    194464        254669       b)    54159        124


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

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

I'll include the -ck2 patch in my testing on other hardware.

--
bill davidsen <[email protected]>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux