On Thu, 31 Oct 2002 12:37:25 -0500 Javier Guerra <listasJGG@eos.com.pe> wrote: > shino korah wrote: > > Hi, > .... snip.... > > This results shows HT improves performance if we have > > 4 tasks on DP system and performance is hit if we use > > 2 tasks on a DP system. > > > > I did use kernel 2.4.9 > > did you repeat the tests several times? > as i remember from ingo's article, he found HT with the non-HT-aware > scheduler (but on 2.5, using O(1)) gave a big variations between the > best and worst time. apparently it was randomly assingning the > processes to the virtual cpus without regard of the real cpu > utilization. > > his HT-aware scheduler didn't get a better performance, but stayed > solidly at the best time he got with the old scheduler > > > > I wrote this to make sure my assumptions are correct > > and I'm getting performance as expected.Correct me if > > I'm wrong. > > i think your 2 process case was degraded becaouse sometimes one (real) > processor had to do all the work and the scheduler didn't noticed the > inbalance; but having 4 processes made it fill every virtual cpu, > achieving real balance just by the coincidence of the numbers > > on the real world you usually don't have as much control on the number > of processes, and very seldom you can start 4 computation-intensive > processes and finish all at roughly the same time I don't think such workloads are so rare, rather a number of common workloads have this "shape" - N computation-intensive processes running at the same time. Note that it doesn't need they to finish at the same time, all you need is when one finishes to have another one ready. Database engines, web server serving dynamic pages, number-crunching problems or plain old "make -j" - all these are common examples of such workloads. Consider IO-bound workloads too - as soon as you have enough processes (i.e. clients) no matter that majority of processes are blocked for IO, there's still sufficient number to saturate the CPU. ~velco -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
