From: Roman Zippel <zippel@linux-m68k.org>
To: Daniel Walker <dwalker@mvista.com>
Cc: akpm@linux-foundation.org, johnstul@us.ibm.com,
ralf@linux-mips.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] clocksource: shift helper
Date: Wed, 7 May 2008 05:57:36 +0200 [thread overview]
Message-ID: <200805070557.39424.zippel@linux-m68k.org> (raw)
In-Reply-To: <20080501173123.444094226@mvista.com>
Hi,
On Thursday 1. May 2008, Daniel Walker wrote:
> This is a little helper I pulled from the mips tree. I've seen a couple
> of bogus shift values, and this helper calculates the shift. This
> should move the shift selection away from the user, and systematically
> pick the value base on the hz.
>
> I also modified the acpi_pm timer to use this new interface. The original
> shift was 22 , and after this patch it's increased to 23. Which should make
> the clocksource slightly more accurate, but shouldn't have much of a
> visible effect.
What is this calculation based on?
Unless I miss something even 22 is far more than enough. acpi_pm has a
resolution of 279ns, thus the clock can't be more accurate than half of this
on average and increasing the shift doesn't change much directly about it.
What the shift value does influence is the size of the adjustment step the
clock code can do during an update, so with shift=22 and HZ=100 the possible
adjustment step would be 0.008ns (freq/2^shift/ntp_hz). The problem is that
this value is also used for how soon the clock is being adjusted, this means
the clock code is constantly busy adjusting for a very small error.
So from a clock adjustment perspective a shift value close to log2
(freq/res/10^9/ntp_hz) (with res=1/freq and being limited to 1ns<=res<=1us)
would provide sufficient accuracy, while keeping the need for adjustment low,
this means with the above example a shift value of much more than 8 doesn't
improve accuracy significantly.
That said, I agree that a dynamic calculation of the shift value is a good
thing, but I don't think that the method in the patch is a good one.
bye, Roman
next prev parent reply other threads:[~2008-05-07 4:05 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-01 17:31 [PATCH] clocksource: shift helper Daniel Walker
2008-05-01 19:32 ` Andrew Morton
2008-05-01 19:48 ` Daniel Walker
2008-05-01 21:05 ` Ralf Baechle
2008-05-06 0:52 ` Thomas Gleixner
2008-05-06 16:39 ` Daniel Walker
2008-05-06 20:25 ` Thomas Gleixner
2008-05-06 20:33 ` Daniel Walker
2008-05-06 20:53 ` Thomas Gleixner
2008-05-06 21:01 ` Daniel Walker
2008-05-06 21:18 ` Andrew Morton
2008-05-06 21:21 ` Thomas Gleixner
2008-05-06 21:19 ` Thomas Gleixner
2008-05-06 21:30 ` Daniel Walker
2008-05-07 16:23 ` Atsushi Nemoto
2008-05-07 3:57 ` Roman Zippel [this message]
2008-05-08 16:48 ` Daniel Walker
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=200805070557.39424.zippel@linux-m68k.org \
--to=zippel@linux-m68k.org \
--cc=akpm@linux-foundation.org \
--cc=dwalker@mvista.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ralf@linux-mips.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