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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 10 Dec 2007 15:04:05 -0500
From:	Jie Chen <chen@...b.org>
To:	Ingo Molnar <mingo@...e.hu>
CC:	linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: Possible bug from kernel 2.6.22 and above, 2.6.24-rc4

Ingo Molnar wrote:
> * Jie Chen <chen@...b.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

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.

-- 
###############################################
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)
chen@...b.org
###############################################

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