lkml.org 
[lkml]   [2013]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] process cputimer is moving faster than its corresponding clock
From
Date
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.





\
 
 \ /
  Last update: 2013-04-27 07:21    [W:0.212 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site