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]
Message-ID: <20070626164907.GF7059@v2.random>
Date:	Tue, 26 Jun 2007 18:49:07 +0200
From:	Andrea Arcangeli <andrea@...e.de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Jesper Juhl <jesper.juhl@...il.com>,
	Roman Zippel <zippel@...ux-m68k.org>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	John Stultz <johnstul@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [patch, v2.6.22-rc6] sys_time() speedup

On Tue, Jun 26, 2007 at 06:18:57PM +0200, Ingo Molnar wrote:
> My patch improves MySQL wall-clock performance by ~10% on a dual-core 
> box [see the numbers i cited in my initial mail, they were ran on a T60 
> with a 1.83 GHz Core2Duo] and by 7% on an 8-way box:

mysql isn't froznen in stone like some commercial db, you can look into its
source, the testsuite isn't either I guess. Did you ask yourself at
least once why it's calling time() so many times per second? The
timestamp sql type should always trigger gettimeofday calls AFIK.

If there's a good reason to call time so frequently in an important
app like mysql, then your patch sure is a good idea, but at first
glance it looks fishy that time is so performance critical.

I'm not objecting the patch itself, if there's a legitimate reason to
call time so frequently that's sure a fine optimization despite the
branch in gettimeofday, but I'm asking why time is called so many
times on this specific workload, because I'm fairly certain that in
average (desktop and server) gettimeofday is called much more
frequently and if it was up to me to tell, I would expect time
microoptimizations to result in irrelevant performance
differences. Infact I seem to recall that even other commercial dbs
calls tends to call floods of gettimeofday while I can't recall any
time in the strace output. So unless there is a legitimate reason to
call time() dozen thousand times per second, if it was my choice, I
would prefer to have gettimeofday as fast as it can be. Not that a
branch will make any measurable difference, but still that would be my
choice.

But perhaps you already know why time is called so frequently, I
certainly don't, nor I would expect it.

Thanks.
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ