Nevermind (me personally) thanks to some kernel tunable ( CONFIG_TICK_CPU_ACCOUNTING ) offered since 3.7, (and AFAIK still default on stock Linux versions) I can still opt for the (good ?) old cheep cpu accounting method since… I (personally) only care about the summ u_time + s_time.It seems hard to believe that time spent blocked (for whatever reason) would be charged as time spent executing-but on the off chance that it is, let's do a quick experiment to get an idea: #include Nevermind, many top rated distro (RHEL, SUZE…) quickly made this virtual cpu time accounting default. Long story made short, around about 2.6.? kernels, linux came with the Virtual CPU time accounting feature providing, among many other things, CPU times accounting, whenever the execution context changes and consequently enabling definitely and precise and accurate u-times and s-times.Īs anywhere, there is no free lunch… (per cpu) timers everywhere… expect some significant overhead. This leading to not only erroneous but completely unrealistic s_time figures. ![]() On systems with virtual CPUs, when using more virtual CPUs than real CPUs on the virtual platform, the real CPUs might spend part of their time servicing another virtual processor while the time slice might be accounted to some process which actually could not utilize it. Only chance, added with a good number of times the task went scheduled in/out in its lifetime can help the cpu time accounting afficionado expecting that errors in + will compensate errors in - and therefore whatever meaningfulness of these values (as taken separately since their sum remains indeed and accurate and meaningful)ī.2/ Error OK but… not THAT much ! So… let's go… virtual! An error that will just be cumulated over time. When some task is scheduled out, the scheduler takes note of the context in which the task was running and… :Ĭpu accounting will just be happy assuming that : all the time the task has been running since it was scheduled in was spent in the context it was running when scheduled out !įrom that, one can understand that debating on the accuracy of the user and system cpu time separate reports because of whatever clock precision is somehow meaningless : There is just an error in the determination of what is what. In the (good ?) old times of Linux (understand < about 2.6.? kernels) cpu accounting was some sort of simple(istic?) heuristic : So who cares for the s/u time ratios ? : cpu accounting afficionados!ī.1/ So… distinguishing u_time and s_time ?… let's… assume! What cputime ? : Grand total of course ! That is to say u_time + s_time since (apart from some very rare exceptions) the scheduler does not care a damn how (in which context) tasks squander their time slices. Precise cputime : Who cares ? The scheduler! The scheduler in its Completely Fair sharing attributions not to forget its obligations to take care of tasks willing to… nanosleep… ![]() System that supports HRTs, the accuracy of sleep and timer systemĬalls is no longer constrained by the jiffy, but instead can be asĪccurate as the hardware allows (microsecond accuracy is typical ofĪs you can read in this overview of time and timers.ī/ How can whatever sort of accuracy regarding utime/stime be achieved if no timer is set right at the beginning of each system call and read right after it completes : Since Linux 2.6.21, Linux supports high-resolution timers (HRTs), On a If not then… you are correct, the precision you report is just… absurd.Ī/ Why getrusage can report timings with a better precision than 1/CONFIG_HZ : So I believe the settings in your system (HAVE_GETRUSAGE…) are appropriate to enable bash not to have to resort to it. ![]() In this precise case, values are indeed reported in clock ticks and you are therefore correct writing that the precision of the values reported just cannot be better than 1/CONFIG_HZ.Īs you might read in the times system call manual page, its use is discouraged for many reasons. In case the times system call is used then bash's time command will output the members of the associated clock_t structure. In case getrusage is used, then bash's time command will use the ru_stime and ru_utime members of the rusage structure and compute the members of their associated timeval structure with, according to the manual page linked herabove, a microsecond accuracy. As you can read from some code #if defined (HAVE_GETRUSAGE) & defined (HAVE_TIMEVAL) & defined (RUSAGE_SELF)ĭepending on HAVE_GETRUSAGE, HAVE_TIMEVAL and RUSAGE_SELF settings, bash's time internal command will either use the getrusage system call or the times system call.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |