Re: [PATCH] process cputimer is moving faster than its corresponding clock

[Olivier Langlois <olivier@trillion01.com>]

On Fri, 2013-04-26 at 22:15 -0400, KOSAKI Motohiro wrote:
> On Fri, Apr 26, 2013 at 9:51 PM, Olivier Langlois
> <olivier@trillion01.com> wrote:
> > On Fri, 2013-04-26 at 15:08 -0400, KOSAKI Motohiro wrote:
> >> > I need to add that I can only confirm that to be true with
> >> > sum_exec_runtime.
> >> >
> >> > To affirm it to be true for stime and utime would require more
> >> > investigation. I didn't look them at all. I was only concerned with
> >> > sum_exec_runtime.
> >> >
> >> > I will prepare a v2 of the patch accounting all the feedbacks that I
> >> > received from KOSAKI Motohiro, Frederic Weisbecker and Peter Zijlstra
> >> > and send it back here for further discussion.
> >> >
> >> > Thank you very much all!
> >>
> >> Do you mean your utime test case still failure? If you share your test-case,
> >> I'm going to look at your issue too.
> >>
> > Sure with pleasure. My testcase is glibc-2.17/rt/tst-cputimer1.c
> >
> > That being said, it strictly test CPUCLOCK_SCHED timers. Hence my focus
> > when modifying the code was strictly on sum_exec_runtime.
> >
> > If utime and stime components of cputimer are moving faster than their
> > associated clock, this is something that I did not address.
> 
> Hmm... Sorry. I'm confused. 1) I haven't seen any glibc test failure
> after applying
> my patch. 2) tst-cputimer1.c only have CLOCK_PROCESS_CPUTIME_ID test and
> don't have any utime, stime tests.
> 
> Please let me know if you've seen any failure after applying my patch.

Basically it is to exclude deltas away from the cputimer initialization
value.

Yes I still have the failure. My patch can be broken into 3 elements.

1. fair.c - cputimer slow down
2. Add deltas to cputimer sample
3. Address race condition

If any of these 3 elements are missing, you get the failure.

That being said, it is not a systematic failure. It is intermittent. I
am wrapping the execution of the unittest into a simple perl script:

#!/usr/bin/perl

use strict;
use warnings;

my $i = 0;

while (system("./tst-cputimer1") == 0) { ++$i; }

print "run $i successful iteration\n";

----------------------------------------

I get the failure after 10-300 iterations depending how I am
lucky/unlucky.

Also other factors to consider it is are you doing the test on a very
loaded system? What is your platform?

I have tested it positively on 32 bit, 64 bits build on Atom N450

i7 first and second generation system.

I did vary HZ from 300 to 1000 HZ, I tried the 3 three different
preemption models.

With all these combinations, I still have the problem.

Basically the timer error is usually < 500 uS so depending when the
process is called as a response to the timer event and this depends on
scheduler decisions, your failure rate will vary depending on the system
load IMO.