From: Ingo Molnar <mingo@elte.hu>
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org, akpm@osdl.org, george@mvista.com,
johnstul@us.ibm.com, paulmck@us.ibm.com
Subject: Re: [ANNOUNCE] ktimers subsystem
Date: Tue, 20 Sep 2005 09:10:10 +0200 [thread overview]
Message-ID: <20050920071010.GA14285@elte.hu> (raw)
In-Reply-To: <Pine.LNX.4.62.0509191521400.27238@schroedinger.engr.sgi.com>
* Christoph Lameter <clameter@engr.sgi.com> wrote:
> > We should rather ask glibc people why gettimeofday() / clock_getttime()
> > is called inside the library code all over the place for non obvious
> > reasons.
>
> You can ask lots of application vendors the same question because its
> all over lots of user space code. The fact is that gettimeofday() /
> clock_gettime() efficiency is very critical to the performance of many
> applications on Linux. That is why the addtion of one add instruction
> may better be carefully considered. Many platforms can execute
> gettimeofday without having to enter the kernel.
i think this line of argument got into a bit of a wrong direction: do we
seriously consider a single 'add' as an argument to _not_ go to a much
cleaner implementation? The answer is very simple: we dont. In the core
kernel we frequently skip other, much worthier micro-optimizations in
favor of cleanliness. The time subsystem has been limping along for
many, many years, and to bring new life into it we need John's and
Thomas's stuff. Simple as that. I'd give up much more than just a single
cycle add overhead for that ...
it's probably not even worth keeping the timespec 'cached' in parallel
to nsec_t - but in any case, speedups like that should be considered
totally separately - cleanliness, the main problem of the whole time
subsystem, comes first. _Once_ cleanliness has been achieved, we can
consider micro-optimizations anew, and judge them by how much they bring
and how they affect cleanliness.
[ Even when not considering cleanliness at all, the best opportunities
for optimizations are elsewhere. E.g. we could speed up
sys_gettimeofday() much more by skipping a number of hardware bug
workarounds that affect the quality of e.g. the TSC, and other timer
hardware details that are simpler on modern hardware. So if someone is
after sys_gettimeofday() performance, dont look for a single add (or
even a single division), go for the bigger picture first. E.g. the
vsyscall people went for the bigger picture on modern platforms and
sped sys_time up by doing it in userspace most of the time and thus
skipping hundreds of cycles of syscall entry overhead - not a cycle
like an add is. ]
Ingo
next prev parent reply other threads:[~2005-09-20 7:17 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-19 16:48 [ANNOUNCE] ktimers subsystem tglx
2005-09-19 16:48 ` [PATCH] " tglx
2005-09-19 21:47 ` [ANNOUNCE] " Thomas Gleixner
2005-09-19 22:03 ` Christoph Lameter
2005-09-19 22:17 ` Thomas Gleixner
2005-09-19 22:24 ` Christoph Lameter
2005-09-19 22:44 ` Thomas Gleixner
2005-09-19 22:50 ` john stultz
2005-09-19 22:58 ` Thomas Gleixner
2005-09-19 23:04 ` Christoph Lameter
2005-09-19 23:12 ` Thomas Gleixner
2005-09-20 7:14 ` Ingo Molnar
2005-09-20 7:10 ` Ingo Molnar [this message]
2005-09-21 19:24 ` Pavel Machek
2005-09-19 22:39 ` Christopher Friesen
2005-09-19 22:54 ` Thomas Gleixner
2005-09-20 4:57 ` Christopher Friesen
2005-09-20 5:11 ` Thomas Gleixner
2005-09-20 0:43 ` George Anzinger
2005-09-21 19:50 ` Roman Zippel
2005-09-21 22:41 ` Thomas Gleixner
2005-09-22 12:59 ` Ingo Molnar
2005-09-22 23:09 ` Roman Zippel
2005-09-22 23:31 ` Christopher Friesen
2005-09-23 0:25 ` Roman Zippel
2005-09-23 6:49 ` Thomas Gleixner
2005-09-24 3:15 ` Roman Zippel
2005-09-24 5:16 ` Ingo Molnar
2005-09-24 10:35 ` Roman Zippel
2005-09-24 13:56 ` Thomas Gleixner
2005-09-24 16:51 ` Daniel Walker
2005-09-24 23:45 ` Roman Zippel
2005-09-25 21:00 ` Thomas Gleixner
2005-09-27 16:54 ` Roman Zippel
2005-09-27 19:03 ` Tim Bird
2005-09-28 16:36 ` Roman Zippel
2005-09-25 21:02 ` Thomas Gleixner
2005-09-27 16:48 ` Roman Zippel
2005-09-27 18:38 ` Tim Bird
2005-09-27 20:36 ` George Anzinger
2005-09-23 2:25 ` john stultz
2005-09-23 8:27 ` Thomas Gleixner
2005-09-24 2:43 ` Roman Zippel
2005-09-24 5:03 ` Ingo Molnar
2005-09-24 9:04 ` James Bruce
2005-09-23 15:21 ` Paul E. McKenney
2005-09-24 3:38 ` Roman Zippel
2005-09-25 15:48 Sid Boyce
2005-09-25 18:20 ` Zwane Mwaikambo
2005-09-26 0:02 ` Sid Boyce
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050920071010.GA14285@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=clameter@engr.sgi.com \
--cc=george@mvista.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@us.ibm.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).