>>> Lars Ellenberg <[email protected]> schrieb am 05.12.2011 um 16:49 in Nachricht <[email protected]>: > On Mon, Dec 05, 2011 at 02:42:54PM +0100, Ulrich Windl wrote: > > >>> Dejan Muhamedagic <[email protected]> schrieb am 05.12.2011 um 13:42 > > >>> in > > Nachricht <[email protected]>: > > > Hi, > > > > > > On Thu, Dec 01, 2011 at 01:52:03PM +0100, Ulrich Windl wrote: > > > > >>> Dejan Muhamedagic <[email protected]> schrieb am 01.12.2011 um > > > > >>> 11:16 in > > > > Nachricht <[email protected]>: > > > > > Hi, > > > > > > > > > > On Thu, Dec 01, 2011 at 08:37:57AM +0100, Ulrich Windl wrote: > > > > > > > > [...] > > > > > > So what are you doing here? > > > > > > > > > > I'm not sure :) You seem to be very proficient at programming, > > > > > why don't then just take a look at the code in glue/clplumbing. > > > > > Search for exec_time. > > > > > > > > Hi! > > > > In which package? pacemaker? CRM? LRM? > > > > > > In cluster-glue. > > > > Hi! > > > > Found the implementation in lib/clplumbing/longclock.c with uses > > times(2) to get the resource usage. The units are measured in "clock > > ticks" which are an obsolete concept by now. As Linux one worked with > > "CLK_TCK == 100", that resolution is a multiple of 10ms. > > > > As it seems, getrusage(2) has a more powerful interface despite of the > > higher resolution clock. > > > > I don't know the motivation for the initial selection of times(). > > Maybe it's that times() existed for more than 30 years. > > That's probably one reason. > > 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 > > 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). > > 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. Regards, Ulrich _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
