Hello Kirill,
Kirill Korotaev wrote:
Hello Maeda,
- AFAIK, "load" is very rough estimation for scheduler, since
processes can fall asleep and awake in such a moments that they won't
be accounted in timer interrupt. We had examples of such loads even
in real life.
I mean how much "fair" is such a scheduler with timeslice-based class
management? Do you have any data on this?
Probably my explanation confused you. Our CPU controller calculate per
class CPU load by own, and it is not equivalent to the load average,
which is an average length of runqueue.
Anyway, the following is a sample results to show how much fair
in terms of CPU proportional ratio. I chose Himeno Benchmark, which is
a CPU intensive work load. It is easy to run benchmark to estimate CPU
MFLOPS. I also run several dhrystone benchmark in background
in order to let the dhrystone eat the all free CPU slots. Otherwise,
Himeno Benchmark uses all CPU resource without regard to the CPU
guarantee.
CPU guarantee Result of Himeno Benchmark Ratio Error
----------------------------------------------------------------------
10% MFLOPS measured : 29.643173 1.0 (Baseline) N/A
20% MFLOPS measured : 64.873545 2.1 +0.1
30% MFLOPS measured : 85.331164 2.9 -0.1
40% MFLOPS measured : 112.614102 3.8 -0.2
50% MFLOPS measured : 141.274826 4.8 -0.2
60% MFLOPS measured : 165.777944 5.6 -0.4
70% MFLOPS measured : 194.094210 6.6 -0.4
80% MFLOPS measured : 248.031517 8.4 +0.4
90% MFLOPS measured : 273.594037 9.2 +0.2
100% MFLOPS measured : 304.113874 10.3 +0.3
There is a trade-off between "fairness" and "scheduling overhead".
I think it is resonably fair, but I'm not sure you think it is fair.
Can you please tell me on what kernel/CKRM version did you obtained
these results?
I used 2.6.14 kernel + ckrm-f0.4-2614.tz with cpurc-v0.2-2416.tz.
We have problems with measuring CPU CKRM controller anyhow because:
- f0.4 CPU controller doesn't make any fairness at all. At least we
can't observer it :)
Could you tell me your measurement condition?
- stable e18 against 2.6.12 oopses :(
maybe we do something wrong and there is some know-how?
Although I'm not a maintainer of the previous CKRM CPU scheduler,
AFAIK, it is not maintained currently.
Another question is:
did you obtain such "fair" results with other classes running or when
the classs in question was the only one in system?
I run several dhrystone benchmark in other class in order to let
them eats surplus cpu time. Otherwise, himeno benchmark eats whole cpu
time without regard to its share.
- another problem with class-based scheduling is preemption of one
class by another like in usual CPU scheduler. I mean the situation
when a task from higher prio class is awaken while a low prio task is
running. Without such "special" preemtion different nasty things can
easily happen - low prio class can consume much more CPU than high
prio one. Does CKRM have any kind of preemption for handling this
situation?
Kirill
Thanks,
MAEDA Naoaki
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
