Messages in this thread | | | Subject | Re: [PATCH] process cputimer is moving faster than its corresponding clock | From | Olivier Langlois <> | Date | Sat, 27 Apr 2013 01:02:23 -0400 |
| |
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.
| |