From: Thomas Gleixner <tglx@linutronix.de>
To: Feng Tang <feng.tang@intel.com>
Cc: John Stultz <john.stultz@linaro.org>, Ingo Molnar <mingo@elte.hu>,
"H. Peter Anvin" <hpa@linux.intel.com>,
Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
x86@kernel.org, Len Brown <lenb@kernel.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
linux-kernel@vger.kernel.org, gong.chen@linux.intel.com
Subject: Re: [PATCH v3 4/5] clocksource: Enable clocksource_cyc2ns() to cover big cycles
Date: Wed, 6 Mar 2013 17:10:53 +0100 (CET) [thread overview]
Message-ID: <alpine.LFD.2.02.1303061701130.22263@ionos> (raw)
In-Reply-To: <20130306143742.GB25790@feng-snb>
On Wed, 6 Mar 2013, Feng Tang wrote:
> Hi Thomas,
>
> Thanks for the reviews.
>
> On Wed, Mar 06, 2013 at 03:09:26PM +0100, Thomas Gleixner wrote:
> > On Wed, 6 Mar 2013, Feng Tang wrote:
> >
> > > Current clocksource_cyc2ns() has a implicit limit that the (cycles * mult)
> > > can not exceed 64 bits limit. Jason Gunthorpe proposed a way to
> > > handle this big cycles case, and this patch put the handling into
> > > clocksource_cyc2ns() so that it could be used unconditionally.
> >
> > Could be used if it wouldn't break the world and some more.
>
> Exactly.
>
> One excuse I can think of is usually the clocksource_cyc2ns() will be called
> for cycles less than 600 seconds, based on which the "mult" and "shift" are
> calculated for a clocksource.
That's not an excuse for making even the build fail on ARM and other
32bit archs.
> > > static inline s64 clocksource_cyc2ns(cycle_t cycles, u32 mult, u32 shift)
> > > {
> > > - return ((u64) cycles * mult) >> shift;
> > > + u64 max = ULLONG_MAX / mult;
> >
> > This breaks everything which does not have a 64/32bit divide
> > instruction. And you can't replace it with do_div() as that would
> > impose massive overhead on those architectures in the fast path.
>
> I thought about this once. And in my v2 patch, I used some code like
>
> + /*
> + * The system suspended time and the delta cycles may be very
> + * long, so we can't call clocksource_cyc2ns() directly with
> + * clocksource's default mult and shift to avoid overflow.
> + */
> + max_cycles = 1ULL << (63 - (ilog2(mult) + 1));
> + while (cycle_delta > max_cycles) {
> + max_cycles <<= 1;
> + mult >>= 1;
> + shift--;
> + }
> +
>
> trying to avoid expensieve maths. But as Jason pointed, there is some accuracy
> lost.
Right, but if you precalculate the max_fast_cycles value you can avoid
at least the division in the fast path and then do
if (cycles > max_fast_cycles)
return clocksource_cyc2ns_slow();
return ((u64) cycles * mult) >> shift;
clocksource_cyc2ns_slow() should be out of line and there you can do
all the slow 64 bit operations. That keeps the fast path sane and we
don't need extra magic for the large cycle values.
Thanks,
tglx
next prev parent reply other threads:[~2013-03-06 16:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-06 7:17 [PATCH v3 0/5] Add support for S3 non-stop TSC support Feng Tang
2013-03-06 7:17 ` [PATCH v3 1/5] x86: Add cpu capability flag X86_FEATURE_NONSTOP_TSC_S3 Feng Tang
2013-03-06 7:17 ` [PATCH v3 2/5] clocksource: Add new feature flag CLOCK_SOURCE_SUSPEND_NONSTOP Feng Tang
2013-03-06 7:17 ` [PATCH v3 3/5] x86: tsc: Add support for new S3_NONSTOP feature Feng Tang
2013-03-06 7:17 ` [PATCH v3 4/5] clocksource: Enable clocksource_cyc2ns() to cover big cycles Feng Tang
2013-03-06 14:09 ` Thomas Gleixner
2013-03-06 14:37 ` Feng Tang
2013-03-06 16:10 ` Thomas Gleixner [this message]
2013-03-06 16:26 ` Feng Tang
2013-03-06 21:05 ` H. Peter Anvin
2013-03-06 21:15 ` Thomas Gleixner
2013-03-06 21:20 ` H. Peter Anvin
2013-03-06 21:29 ` Thomas Gleixner
2013-03-06 7:17 ` [PATCH v3 5/5] timekeeping: utilize the suspend-nonstop clocksource to count suspended time Feng Tang
2013-03-06 14:15 ` Thomas Gleixner
2013-03-06 14:29 ` Feng Tang
2013-03-06 21:33 ` Thomas Gleixner
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=alpine.LFD.2.02.1303061701130.22263@ionos \
--to=tglx@linutronix.de \
--cc=feng.tang@intel.com \
--cc=gong.chen@linux.intel.com \
--cc=hpa@linux.intel.com \
--cc=jgunthorpe@obsidianresearch.com \
--cc=john.stultz@linaro.org \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rafael.j.wysocki@intel.com \
--cc=x86@kernel.org \
/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