2006/1/26, Chandra Seetharaman <[EMAIL PROTECTED]>: > BTW, is this with the problem you reported on fork() and exit() > overhead ?
I hardly think so. Because lat_ctx only measures between after fork and before exit in order to avoid the cost of fork() and exit(). > On Tue, 2006-01-24 at 18:25 +0900, MAEDA Naoaki wrote: > > Hi all, > > > > I've taken some benchmark results of cpurc-v0.3-2615 in order to > > measure its overhead and the accuracy of enforced CPU share. > > > > 1) Overhead measurement with lat_ctx -s 0 in various # of processes > > > > The overhead is between -0.02 to +0.07 microseconds. > > It is quite small. > > > > # Vanilla 2.6.15 2.6.15+cpurc-v0.3 Diff [us] > > --------------------------------------------------------- > > 2 0.51 0.52 +0.01 > > 4 0.58 0.6 +0.02 > > 8 0.71 0.71 0.0 > > 16 0.72 0.72 0.0 > > 32 0.73 0.72 -0.01 > > 64 0.78 0.85 +0.07 > > 128 1.08 1.06 -0.02 > > 256 1.85 1.89 +0.04 > > ---------------------------------------------------------- > > > > 2) CPU share enforcement test with kernbench > > > > User and Sys time are almost constant in every case. > > On the other hand, enforcing shares are _roughly_ equal to > > the percentages of CPU consumed by kernbench. It is not too bad, > > but further investigation is needed. > > > > Share[%] Elaps[s] User[s] Sys[s] CPU[%] > > ---------------------------------------------- > > 100 321.9 295.1 19.7 97.0 > > 90 325.4 293.5 19.5 95.8 > > 80 345.9 293.2 19.7 90.0 > > 70 392.6 293.3 19.6 79.2 > > 60 466.0 293.6 19.8 66.8 > > 50 583.0 296.4 19.8 53.8 > > 40 725.3 297.7 19.6 43.2 > > 30 925.2 299.6 19.4 34.0 > > 20 1458.2 301.5 19.3 21.2 > > 10 2595.5 303.4 20.0 12.0 > > ---------------------------------------------- > > > > - One class for running kernbench was defined and various > > share was set to the class. > > > > - kernbench -M against 2.6.15 kernel source > > > > - Five infinity loop programs were running on the default_class > > at the same time. Otherwise, kernbench was able to consume > > all of the CPU resource. > > > > 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > > _______________________________________________ > > ckrm-tech mailing list > > https://lists.sourceforge.net/lists/listinfo/ckrm-tech > > > -- > > ---------------------------------------------------------------------- > Chandra Seetharaman | Be careful what you choose.... > - [EMAIL PROTECTED] | .......you may get it. > ---------------------------------------------------------------------- > > > > > ------------------------------------------------------- > 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > ckrm-tech mailing list > https://lists.sourceforge.net/lists/listinfo/ckrm-tech > ------------------------------------------------------- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
