From: Alex Williamson <alex.williamson@hp.com>
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: tony.luck@intel.com, linux-kernel@vger.kernel.org
Subject: Re: long delays (possibly infinite) in time_interpolator_get_counter
Date: Sun, 31 Jul 2005 11:02:59 -0600 [thread overview]
Message-ID: <1122829379.6946.11.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.62.0507301105120.25104@schroedinger.engr.sgi.com>
Ok, here's an optimization that should help reduce contention on the
cmpxchg, has zero impact on the nojitter path, and doesn't require any
changes to fsys. When a caller already had the xtime_lock write lock
there's no need to fight with other CPUs for the cmpxchg. The other
"reader" CPUs will have to fetch it again since a seqlock write is in
progress. Therefore we can simplify this path as shown below. The
write is atomic, and we don't care if another CPU has changed last_cycle
since it can't return the value until the write lock is released. This
has only been compile tested, but I'm interested to hear your opinion.
Thanks,
Alex
diff -r cff8d3633e9c kernel/timer.c
--- a/kernel/timer.c Fri Jul 29 22:01:15 2005
+++ b/kernel/timer.c Sun Jul 31 10:25:41 2005
@@ -1452,10 +1452,34 @@
return time_interpolator_get_cycles(src);
}
+static inline u64 time_interpolator_get_counter_locked(void)
+{
+ unsigned int src = time_interpolator->source;
+
+ if (time_interpolator->jitter)
+ {
+ u64 lcycle = time_interpolator->last_cycle;
+ u64 now = time_interpolator_get_cycles(src);
+
+ if (lcycle && time_after(lcycle, now))
+ return lcycle;
+
+ /*
+ * This path is called when holding the xtime write lock.
+ * This allows us to avoid the contention of the cmpxchg
+ * in get_counter, and still ensures jitter protection.
+ */
+ time_interpolator->last_cycle = now;
+ return now;
+ }
+ else
+ return time_interpolator_get_cycles(src);
+}
+
void time_interpolator_reset(void)
{
time_interpolator->offset = 0;
- time_interpolator->last_counter = time_interpolator_get_counter();
+ time_interpolator->last_counter = time_interpolator_get_counter_locked();
}
#define GET_TI_NSECS(count,i) (((((count) - i->last_counter) & (i)->mask) * (i)->nsec_per_cyc) >> (i)->shift)
@@ -1490,7 +1514,7 @@
* and the tuning logic insures that.
*/
- counter = time_interpolator_get_counter();
+ counter = time_interpolator_get_counter_locked();
offset = time_interpolator->offset + GET_TI_NSECS(counter, time_interpolator);
if (delta_nsec < 0 || (unsigned long) delta_nsec < offset)
next prev parent reply other threads:[~2005-07-31 17:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-29 22:06 long delays (possibly infinite) in time_interpolator_get_counter tony.luck
2005-07-29 23:31 ` Christoph Lameter
2005-07-30 16:47 ` Alex Williamson
2005-07-30 18:10 ` Christoph Lameter
2005-07-31 17:02 ` Alex Williamson [this message]
2005-07-31 20:00 ` Christoph Lameter
2005-08-01 16:57 ` Bjorn Helgaas
2005-08-01 17:04 ` Christoph Lameter
2005-07-30 0:32 ` Christoph Lameter
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=1122829379.6946.11.camel@localhost.localdomain \
--to=alex.williamson@hp.com \
--cc=clameter@engr.sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tony.luck@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.