Re: Possible bug from kernel 2.6.22 and above, 2.6.24-rc4




* Jie Chen <chen@xxxxxxxx> wrote:

and then you use this in the measurement loop:

for (k=0; k<=OUTERREPS; k++){
start = getclock();
for (j=0; j<innerreps; j++){
#ifdef _QMT_PUBLIC
delay((void *)0, 0);
#else
delay(0, 0, 0, (void *)0);
#endif
}
times[k] = (getclock() - start) * 1.0e6 / (double) innerreps;
}

the problem is, this does not take the overhead of gettimeofday into
account - which overhead can easily reach 10 usecs (the observed
regression). Could you try to eliminate the gettimeofday overhead from
your measurement?

gettimeofday overhead is something that might have changed from .21 to .22
on your box.

Ingo

Hi, Ingo:

In my pthread_sync code, I first call refer () subroutine which
actually establishes the elapsed time (reference time) for
non-synchronized delay() using the gettimeofday. Then each
synchronization overhead value is obtained by subtracting the
reference time from the elapsed time with introduced synchronization.
The effect of gettimeofday() should be minimal if the time difference
(overhead value) is the interest here. Unless the gettimeofday behaves
differently in the case of running 8 threads .vs. running 2 threads.

I will try to replace gettimeofday with a lightweight timer call in my
test code. Thank you very much.

gettimeofday overhead is around 10 usecs here:

2740 1197359374.873214 gettimeofday({1197359374, 873225}, NULL) = 0 <0.000010>
2740 1197359374.970592 gettimeofday({1197359374, 970608}, NULL) = 0 <0.000010>

and that's the only thing that is going on when computing the reference
time - and i see a similar syscall pattern in the PARALLEL and BARRIER
calculations as well (with no real scheduling going on).

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • Re: Possible bug from kernel 2.6.22 and above, 2.6.24-rc4
    ... this does not take the overhead of gettimeofday into account - which overhead can easily reach 10 usecs. ... I first call refer subroutine which actually establishes the elapsed time (reference time) for non-synchronized delayusing the gettimeofday. ... The results of pthread_sync is the same as the non-patched 2.6.21 kernel. ...
    (Linux-Kernel)
  • Re: Possible bug from kernel 2.6.22 and above, 2.6.24-rc4
    ... this does not take the overhead of gettimeofday into account - which overhead can easily reach 10 usecs. ... I first call refer subroutine which actually establishes the elapsed time (reference time) for non-synchronized delayusing the gettimeofday. ... Then each synchronization overhead value is obtained by subtracting the reference time from the elapsed time with introduced synchronization. ...
    (Linux-Kernel)
  • Re: How is Code in do_sys_settimeofday() safe in case of SMP and Nest Kernel Path?
    ... I really hate adding overhead to gettimeofday() and we would have to take ... resulting race? ... So we may get daylight savings time wrong. ...
    (Linux-Kernel)
  • Re: benchmark
    ... for Pentium D 2.8Ghz. ... May be, a netgraph node? ... I don't like iperf for gettimeofday() overhead. ...
    (freebsd-performance)
  • Re: benchmark
    ... for Pentium D 2.8Ghz. ... May be, a netgraph node? ... I don't like iperf for gettimeofday() overhead. ...
    (freebsd-stable)