From: Ingo Molnar <mingo@elte.hu>
To: john stultz <johnstul@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@tglx.de>, Andi Kleen <ak@suse.de>,
nikolag@ca.ibm.com, Darren Hart <dvhltc@us.ibm.com>
Subject: Re: [RFC][PATCH] Introduce CLOCK_REALTIME_COARSE
Date: Sat, 18 Jul 2009 14:09:39 +0200 [thread overview]
Message-ID: <20090718120939.GC31007@elte.hu> (raw)
In-Reply-To: <1247873945.8334.67.camel@localhost.localdomain>
* john stultz <johnstul@us.ibm.com> wrote:
> Hey all,
>
> After talking with some application writers who want very
> fast, but not fine-grained timestamps, I decided to try to
> implement a new clock_ids to clock_gettime():
> CLOCK_REALTIME_COARSE and CLOCK_MONOTONIC_COARSE which returns the
> time at the last tick. This is very fast as we don't have to
> access any hardware (which can be very painful if you're using
> something like the acpi_pm clocksource), and we can even use the
> vdso clock_gettime() method to avoid the syscall. The only trade
> off is you only get low-res tick grained time resolution.
>
> This isn't a new idea, I know Ingo pushed a patch (see commit
> 5899a0f044f3c80e9f7262ec5bc7164773a4c28e) a little while ago that
> made the vsyscall gettimeofday() return coarse grained time when
> the vsyscall64 sysctrl was set to 2. However this affects all
> applications on a system.
Note, that patch is an -rt commit, right? I.e. not yet upstream.
> With this method, applications can choose the proper
> speed/granularity trade-off for themselves.
>
> This is a first pass on this implementation, and while I did test
> it, the box I tested it with did not have a glibc new enough to
> utilize the vdso clock_gettime(), so there may still be issues
> there. I'll find a newer box for testing shortly.
>
> Any thoughts or feedback will be appreciated!
Looks good. I think we should offer both methods: your patch as an
unconditional 'coarse time' approximator always available
everywhere, plus the vsyscall redirector as well from -rt, to allow
admins/users to tweak in a global way on apps that cannot be
changed.
Ingo
next prev parent reply other threads:[~2009-07-18 12:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-17 23:39 [RFC][PATCH] Introduce CLOCK_REALTIME_COARSE john stultz
2009-07-18 8:30 ` Thomas Gleixner
2009-07-18 22:09 ` john stultz
2009-07-18 22:30 ` Arjan van de Ven
2009-07-20 11:17 ` Peter Zijlstra
2009-07-20 12:22 ` Paul E. McKenney
2009-07-20 13:33 ` Arjan van de Ven
2009-07-20 13:49 ` Peter Zijlstra
2009-07-22 21:39 ` Josh Triplett
2009-07-21 22:31 ` john stultz
2009-07-22 1:26 ` john stultz
2009-08-01 12:21 ` Andy Lutomirski
2009-07-18 12:09 ` Ingo Molnar [this message]
2009-07-18 22:20 ` john stultz
2009-07-19 3:00 ` Chris Snook
2009-07-19 6:14 ` Arjan van de Ven
2009-07-19 6:48 ` Nicholas Miell
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=20090718120939.GC31007@elte.hu \
--to=mingo@elte.hu \
--cc=ak@suse.de \
--cc=dvhltc@us.ibm.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nikolag@ca.ibm.com \
--cc=tglx@tglx.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