From: john stultz <johnstul@us.ibm.com>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
lkml <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@tglx.de>, Ingo Molnar <mingo@elte.hu>,
Andi Kleen <ak@suse.de>,
nikolag@ca.ibm.com, Darren Hart <dvhltc@us.ibm.com>
Subject: Re: [RFC][PATCH] Introduce CLOCK_REALTIME_COARSE
Date: Tue, 21 Jul 2009 15:31:19 -0700 [thread overview]
Message-ID: <1248215479.3298.124.camel@localhost> (raw)
In-Reply-To: <20090718153011.1de3af8e@infradead.org>
On Sat, 2009-07-18 at 15:30 -0700, Arjan van de Ven wrote:
> On Sat, 18 Jul 2009 15:09:38 -0700
> john stultz <johnstul@us.ibm.com> wrote:
>
> > 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.
>
> Does this tie us to having a tick? I still have hope that we can get
> rid of the tick even when apps are running .... since with CFS we don't
> really need the tick for the scheduler anymore for example....
So it does require some sort of periodic interval. But the granularity
is probably flexible, although I'm not sure it would be of much use if
the granularity gets to be lower then 100hz.
While being 100% tickless, even when non-idle would be nice, there will
be some need for timekeeping events to prevent clocksource counters from
wrapping, and to do accurate NTP steering.
Even so, the value we're exporting in this patch is the xtime_cache,
which is updated every tick. This is currently used in file
timestamping, so if we go 100% tickless, we'll have to change the file
timestamping to use the actual CLOCK_REALTIME clock_id, which requires a
possibly slow hardware read and would likely hurt fs performance.
So this patch doesn't so much tie us to having a tick or periodic event
any more the the fs timestamping does.
> > me_lock, seq));
> > +
> > + set_normalized_timespec(&now, now.tv_sec + mono.tv_sec,
> > + now.tv_nsec + mono.tv_nsec);
> > + return now;
> > +}
> > +EXPORT_SYMBOL(get_monotonic_coarse);
> > +
>
> why does this need to be exported ?
Doesn't. Thanks for noticing!
thanks
-john
next prev parent reply other threads:[~2009-07-21 22:31 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 [this message]
2009-07-22 1:26 ` john stultz
2009-08-01 12:21 ` Andy Lutomirski
2009-07-18 12:09 ` Ingo Molnar
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=1248215479.3298.124.camel@localhost \
--to=johnstul@us.ibm.com \
--cc=ak@suse.de \
--cc=arjan@infradead.org \
--cc=dvhltc@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nikolag@ca.ibm.com \
--cc=tglx@linutronix.de \
--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