* Jie Chen <[email protected]> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- Re: Possible bug from kernel 2.6.22 and above, 2.6.24-rc4
- Re: Possible bug from kernel 2.6.22 and above, 2.6.24-rc4
- Re: Possible bug from kernel 2.6.22 and above, 2.6.24-rc4
- Re: Possible bug from kernel 2.6.22 and above, 2.6.24-rc4
- Re: Possible bug from kernel 2.6.22 and above, 2.6.24-rc4
- Re: Possible bug from kernel 2.6.22 and above, 2.6.24-rc4
- Re: Possible bug from kernel 2.6.22 and above, 2.6.24-rc4
- Re: Possible bug from kernel 2.6.22 and above, 2.6.24-rc4
- Re: Possible bug from kernel 2.6.22 and above, 2.6.24-rc4
- Re: Possible bug from kernel 2.6.22 and above, 2.6.24-rc4
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]