On Tue, Dec 06, 2011 at 08:31:39AM +0100, Ulrich Windl wrote: > > Requirements for the return value of "time_longclock()" > > (which is what actually should be used) > > are at least: > > It must be monotonic, no jumping backwards. > > It must not care for the wall clock time > > (ignore any jumping around caused by "date --set" or equivalent, > > so gettimeofday or similar are out). > > It must not care which CPU it runs on. > > It must be portable. > > > > It should be as linear as possible wrt actually elapsed real time, > > not return a diff of 100 for one elapsed second, and some time > > later return a diff of 117 for the same "real time" period. > > > > The return value of times(), (wrapped in time_longclock(), if > > sizeof(clock_t) < 8) meets those requirements. > > > > I don't see how getrusage would meet these requirements. > > Oops! ??? > > I don't see why resource usage shouldn't be > monotonic > independent of wall-time > independent of the CPU it runs on > portable
It measures resource usage. Depending on how "busy" this process or the overall system was, it will not be "linear" wrt actually elapsed real time. "Resource usage units" can not be converted back to "real time ms", for example. What we typically care about is the elapsed real time. Besides, at least on the box I just tried (2.6.32 kernel), getrusage returns just the same granularity of 0.01 seconds, so you'd be back to square one, even if it met the other requirements :) > > So if you want to hack something up with getrusage, > > restrict that to a certain usage of time_longclock(), > > not to the implementation of time_longclock() itself. > > I don't think that "longclock" stuff is actually needed at all (unless I > overlooked something). You probably have. 32bit wrap around, for example. > > If you find something that fullfills those requirements, > > so could possibly be used instead of times() in the > > implementation of cl_times(), go ahead and suggest it. > > > > clock_gettime with CLOCK_MONOTONIC may be a candidate. > > > > But really: just to get some sub 10ms granularity of "exec time"? > > Why even bother. > > Because I can complete a whole complex job in just a fraction of 10ms. Even if that statement may be true, what is its relevance? Having lrmd report "5ms" instead of "10ms" (or "0ms", I did not check if it does ceil, round, or floor the value) makes a difference because ...? It makes you feel better? There is no better reason than that, I suppose :) As I said: if you want to change how time is tracked in the mainloop queue, waiting queue because of "max-children" or for whatever reason, and the actual exec time from fork to sigchld processing, that's a specific scope, no problem to replace time_longclock there with gettimeofday, or whatever you feel gives you the most pleasure (getrusage is not it, I dare say). If the patch is small and consistent, it may even go upstream ;) The point I was trying to make is: if you attempt to replace time_longclock altogether, be aware that this would have more implications. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com _______________________________________________ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
