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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

Ingo Molnar wrote:

* Jie Chen <[email protected]> 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


Hi, Ingo:
I guess it is a good news. I did patch 2.6.21.7 kernel using your cfs patch. The results of pthread_sync is the same as the non-patched 2.6.21 kernel. This means the performance of is not related to the scheduler. As for overhead of the gettimeofday, there is no difference between 2.6.21 and 2.6.24-rc4. The reference time is around 10.5 us for both kernel.
So what is changed between 2.6.21 and 2.6.22? Any hints :-). Thank you very much for all your help. 

--
###############################################
Jie Chen
Scientific Computing Group
Thomas Jefferson National Accelerator Facility
12000, Jefferson Ave.
Newport News, VA 23606

(757)269-5046 (office) (757)269-6248 (fax)
[email protected]
###############################################

--
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/
[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]
  Powered by Linux