Messages in this thread | | | Date | Mon, 10 Dec 2007 11:59:44 +0100 | From | Ingo Molnar <> | Subject | Re: Possible bug from kernel 2.6.22 and above, 2.6.24-rc4 |
| |
* Jie Chen <chen@jlab.org> wrote:
> I did patch the header file and recompiled the kernel. I observed no > difference (two threads overhead stays too high). Thank you.
ok, i think i found it. You do this in your qmt/pthread_sync.c test-code:
double get_time_of_day_() { ... err = gettimeofday(&ts, NULL); ... }
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
| |