sting applications it
would break.
--
Miroslav Lichvar
executed and has not yet managed to rearm the hrtimer.
>
> Not a big problem as it just schedules work for nothing.
No more unexpected updates of the RTC observed.
Tested-by: Miroslav Lichvar
Thanks,
--
Miroslav Lichvar
On Wed, Dec 02, 2020 at 04:07:28PM +0100, Miroslav Lichvar wrote:
> On Wed, Dec 02, 2020 at 02:44:53PM +0100, Thomas Gleixner wrote:
> > Something like the completely untested below should make this reliable
> > and only needs to retry when the work is running lat
ime.
Thanks,
--
Miroslav Lichvar
the counter when the check finally succeeds. This will
allow the RTC update to keep good accuracy if it can happen in the first
few attempts and it will not take more than a minute if the timing is
consistently bad for any reason.
Signed-off-by: Miroslav Lichvar
Cc: Thomas Gleixner
Cc: John Stultz
On Tue, Dec 01, 2020 at 12:12:24PM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 01, 2020 at 03:38:35PM +0100, Miroslav Lichvar wrote:
> > + unsigned long time_set_nsec_fuzz;
> > + static unsigned int attempt;
>
> Adding a static value instide a static inline should not be
succeeds. This should allow the RTC update to happen in
a minute at most.
Signed-off-by: Miroslav Lichvar
Cc: Thomas Gleixner
Cc: John Stultz
Cc: Prarit Bhargava
Cc: Jason Gunthorpe
---
include/linux/rtc.h | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git
On Wed, Aug 21, 2019 at 11:53:12AM +0200, Hubert Feurstein wrote:
> Am Mi., 21. Aug. 2019 um 10:07 Uhr schrieb Miroslav Lichvar
> > Because those reports/statistics are important in calculation of
> > maximum error. If someone had a requirement for a clock to be accurate
> >
On Tue, Aug 20, 2019 at 06:56:56PM +0200, Hubert Feurstein wrote:
> Am Di., 20. Aug. 2019 um 17:40 Uhr schrieb Miroslav Lichvar
> > I think a large jitter is ok in this case. We just need to timestamp
> > something that we know for sure happened after the PHC timestamp. It
minimum interrupt delay, I'd still
prefer an overly pessimistic interval assuming a zero delay.
--
Miroslav Lichvar
On Tue, Aug 20, 2019 at 02:29:27PM +0200, Hubert Feurstein wrote:
> Am Di., 20. Aug. 2019 um 11:49 Uhr schrieb Miroslav Lichvar
> > This is important to not break the estimation of maximum error in the
> > measured offset. Applications using the ioctl may assume that the
&g
-pre_ts)/2 (i.e. half of the delay printed by
phc2sys). That would not work if the delay could be occasionally 50
microseconds for instance, i.e. the post_ts timestamp would be earlier
than the PHC timestamp.
--
Miroslav Lichvar
u don't have to change the API, like you did with
> mdiobus_write_nested_ptp. Relatively speaking, this is the least
> amount of intrusion (although, again, far from beautiful).
That would make sense to me, if there are other drivers that could use
it.
> I also added Miroslav Lichvar, w
Commit-ID: d21e43f2ef32ba3242687dbedb3c4b9a76b3eebc
Gitweb: https://git.kernel.org/tip/d21e43f2ef32ba3242687dbedb3c4b9a76b3eebc
Author: Miroslav Lichvar
AuthorDate: Tue, 18 Jun 2019 18:06:12 +0200
Committer: Thomas Gleixner
CommitDate: Sat, 22 Jun 2019 11:28:53 +0200
kselftests
Commit-ID: d897a4ab11dc8a9fda50d2eccc081a96a6385998
Gitweb: https://git.kernel.org/tip/d897a4ab11dc8a9fda50d2eccc081a96a6385998
Author: Miroslav Lichvar
AuthorDate: Tue, 18 Jun 2019 17:47:13 +0200
Committer: Thomas Gleixner
CommitDate: Sat, 22 Jun 2019 11:28:53 +0200
ntp: Limit TAI
yd
Signed-off-by: Miroslav Lichvar
---
tools/testing/selftests/timers/freq-step.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/timers/freq-step.c
b/tools/testing/selftests/timers/freq-step.c
index 8cd10662ffba..4b76450d78d1 100644
--- a/too
: Stephen Boyd
Cc: Thomas Gleixner
Signed-off-by: Miroslav Lichvar
---
kernel/time/ntp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 8de4f789dc1b..65eb796610dc 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -43,6
aybe it would make sense to
specify a much smaller maximum like 100?
Even 1000 should be good enough for near future. Negative values are
not allowed anyway. If the Earth's rotation changed significantly
(e.g. hitting a very large asteroid), there probably wouldn't be
anyone left to care about TAI.
--
Miroslav Lichvar
Commit-ID: fdc6bae940ee9eb869e493990540098b8c0fd6ab
Gitweb: https://git.kernel.org/tip/fdc6bae940ee9eb869e493990540098b8c0fd6ab
Author: Miroslav Lichvar
AuthorDate: Wed, 17 Apr 2019 10:48:33 +0200
Committer: Thomas Gleixner
CommitDate: Thu, 9 May 2019 10:46:58 +0200
ntp: Allow TAI-UTC
On Wed, Apr 17, 2019 at 11:00:23AM +0200, Ondrej Mosnacek wrote:
> On Wed, Apr 17, 2019 at 10:48 AM Miroslav Lichvar wrote:
> > Change the ADJ_TAI check to accept zero as a valid TAI-UTC offset in
> > order to allow setting it back to the initial value.
> Thanks for sending th
t Bhargava
Suggested-by: Ondrej Mosnacek
Signed-off-by: Miroslav Lichvar
---
kernel/time/ntp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index 92a90014a925..f43d47c8c3b6 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -69
gt; 0?
I guess zero here means "unknown" and maybe the intention was to not
allow setting the offset to an unknown value once it has been set to a
valid value. The trouble is that after inserting a leap second the
offset may change from zero to one.
I think it should be changed to allow setting the offset to zero.
--
Miroslav Lichvar
ght possibly
break more tests (or any unusual applications messing with time) as a
much larger interval is now EINVAL.
Thanks,
--
Miroslav Lichvar
tself. ktime_t
overflows on Apr 11 2262. clock_settime() and adjtimex(ADJ_SETOFFSET)
can set the time close to the overflow and let everything break.
Boot a VM and try this:
# date -s 'Apr 11 23:47:15 UTC 2262'
There was a patch submitted couple years ago that prevented overflows
in 32-bit time_t
On Fri, Nov 02, 2018 at 12:25:56PM +0100, Thomas Gleixner wrote:
> On Fri, 2 Nov 2018, Miroslav Lichvar wrote:
> > clocksource -> MONOTONIC_RAW -> MONOTONIC/REALTIME
> >
> > or
> >
> > clocksource -> ? -> MONOTONIC_RAW
> >
On Fri, Nov 02, 2018 at 12:25:56PM +0100, Thomas Gleixner wrote:
> On Fri, 2 Nov 2018, Miroslav Lichvar wrote:
> > clocksource -> MONOTONIC_RAW -> MONOTONIC/REALTIME
> >
> > or
> >
> > clocksource -> ? -> MONOTONIC_RAW
> >
k which is
separate from the mono/real clock, and add an offset to the NTP
frequency to match the frequencies of the two clocks when not
synchronized by NTP/PTP. The latter would provide a more stable
mono/real clock.
clocksource -> MONOTONIC_RAW -> MONOTONIC/REALTIME
or
clocksource -> ? -> MONOTONIC_RAW
-> MONOTONIC/REALTIME
--
Miroslav Lichvar
k which is
separate from the mono/real clock, and add an offset to the NTP
frequency to match the frequencies of the two clocks when not
synchronized by NTP/PTP. The latter would provide a more stable
mono/real clock.
clocksource -> MONOTONIC_RAW -> MONOTONIC/REALTIME
or
clocksource -> ? -> MONOTONIC_RAW
-> MONOTONIC/REALTIME
--
Miroslav Lichvar
On Thu, Nov 01, 2018 at 06:41:00PM +0100, Thomas Gleixner wrote:
> On Wed, 24 Oct 2018, Miroslav Lichvar wrote:
> > The error is too large to be corrected by stepping on clock updates.
> > For a typical TSC frequency we have multiplier in the range of few
> > millions, so tha
On Thu, Nov 01, 2018 at 06:41:00PM +0100, Thomas Gleixner wrote:
> On Wed, 24 Oct 2018, Miroslav Lichvar wrote:
> > The error is too large to be corrected by stepping on clock updates.
> > For a typical TSC frequency we have multiplier in the range of few
> > millions, so tha
On Wed, Oct 24, 2018 at 01:32:48PM -0400, Christopher Hall wrote:
> On Wed, Oct 24, 2018 at 04:51:13PM +0200, Miroslav Lichvar wrote:
> > The error is too large to be corrected by stepping on clock updates.
> > For a typical TSC frequency we have multiplier in the range of few
&
On Wed, Oct 24, 2018 at 01:32:48PM -0400, Christopher Hall wrote:
> On Wed, Oct 24, 2018 at 04:51:13PM +0200, Miroslav Lichvar wrote:
> > The error is too large to be corrected by stepping on clock updates.
> > For a typical TSC frequency we have multiplier in the range of few
&
onized CPUs)?
If the frequency error was exported, it could be compensated where
necessary. Maybe that would work for the original poster?
A better fix might be to modify the calculation of time to use a
second multiplier, effectively increasing its resolution. However,
that would slow down all users of the clock.
--
Miroslav Lichvar
onized CPUs)?
If the frequency error was exported, it could be compensated where
necessary. Maybe that would work for the original poster?
A better fix might be to modify the calculation of time to use a
second multiplier, effectively increasing its resolution. However,
that would slow down all users of the clock.
--
Miroslav Lichvar
}
> printf("[FAILED]\n");
> return ksft_exit_fail();
> }
> --
> 2.7.4
>
--
Miroslav Lichvar
}
> printf("[FAILED]\n");
> return ksft_exit_fail();
> }
> --
> 2.7.4
>
--
Miroslav Lichvar
T in progress. Shutdown
NTPd or other time steering daemons\n");
+ return ksft_exit_skip("The clock was adjusted. Shutdown
ntpd or other time steering daemons\n");
}
printf(" [FAILED]\n");
return ksft_exit_fail();
--
Miroslav Lichvar
T in progress. Shutdown
NTPd or other time steering daemons\n");
+ return ksft_exit_skip("The clock was adjusted. Shutdown
ntpd or other time steering daemons\n");
}
printf(" [FAILED]\n");
return ksft_exit_fail();
--
Miroslav Lichvar
control of the system clock
with update rates close to or even exceeding the kernel HZ.
The update is limited to archs using modern timekeeping
(!ARCH_USES_GETTIMEOFFSET).
Cc: Thomas Gleixner
Cc: John Stultz
Cc: Richard Cochran
Cc: Prarit Bhargava
Signed-off-by: Miroslav Lichvar
---
Notes:
RFC
control of the system clock
with update rates close to or even exceeding the kernel HZ.
The update is limited to archs using modern timekeeping
(!ARCH_USES_GETTIMEOFFSET).
Cc: Thomas Gleixner
Cc: John Stultz
Cc: Richard Cochran
Cc: Prarit Bhargava
Signed-off-by: Miroslav Lichvar
---
Notes:
RFC
On Tue, May 29, 2018 at 10:42:05AM -0700, John Stultz wrote:
> On Tue, May 29, 2018 at 3:53 AM, Miroslav Lichvar wrote:
> > -void update_wall_time(void)
> > +static void timekeeping_advance(bool force_update)
>
> This is kind of a nit, but mind switching out bool for an enu
On Tue, May 29, 2018 at 10:42:05AM -0700, John Stultz wrote:
> On Tue, May 29, 2018 at 3:53 AM, Miroslav Lichvar wrote:
> > -void update_wall_time(void)
> > +static void timekeeping_advance(bool force_update)
>
> This is kind of a nit, but mind switching out bool for an enu
control of the system clock
with update rates close to or even exceeding the kernel HZ.
Cc: Thomas Gleixner
Cc: John Stultz
Cc: Richard Cochran
Cc: Prarit Bhargava
Signed-off-by: Miroslav Lichvar
---
Notes:
RFC->v1:
- added a new parameter to force the update of the timekee
control of the system clock
with update rates close to or even exceeding the kernel HZ.
Cc: Thomas Gleixner
Cc: John Stultz
Cc: Richard Cochran
Cc: Prarit Bhargava
Signed-off-by: Miroslav Lichvar
---
Notes:
RFC->v1:
- added a new parameter to force the update of the timekee
On Wed, May 23, 2018 at 11:05:34AM -0700, John Stultz wrote:
> On Wed, May 23, 2018 at 4:33 AM, Miroslav Lichvar <mlich...@redhat.com> wrote:
> > This removes a hidden non-deterministic delay in setting of the
> > frequency and allows an extremely tight control of the system
On Wed, May 23, 2018 at 11:05:34AM -0700, John Stultz wrote:
> On Wed, May 23, 2018 at 4:33 AM, Miroslav Lichvar wrote:
> > This removes a hidden non-deterministic delay in setting of the
> > frequency and allows an extremely tight control of the system clock
> > wi
control of the system clock
with update rates close to or even exceeding the kernel HZ.
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: John Stultz <john.stu...@linaro.org>
Cc: Richard Cochran <richardcoch...@gmail.com>
Cc: Prarit Bhargava <pra...@redhat.com>
Signed-off-by:
control of the system clock
with update rates close to or even exceeding the kernel HZ.
Cc: Thomas Gleixner
Cc: John Stultz
Cc: Richard Cochran
Cc: Prarit Bhargava
Signed-off-by: Miroslav Lichvar
---
kernel/time/timekeeping.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
may fail.
Maybe this test and other tests that measure the frequency of the
system clock should be modified to SKIP when adjtimex() returns a
non-zero offset (or the frequency changes during the test)?
--
Miroslav Lichvar
may fail.
Maybe this test and other tests that measure the frequency of the
system clock should be modified to SKIP when adjtimex() returns a
non-zero offset (or the frequency changes during the test)?
--
Miroslav Lichvar
: Prarit Bhargava <pra...@redhat.com>
Cc: Richard Cochran <richardcoch...@gmail.com>
Cc: Stephen Boyd <stephen.b...@linaro.org>
Signed-off-by: Miroslav Lichvar <mlich...@redhat.com>
---
tools/testing/selftests/timers/freq-step.c | 6 +++---
1 file changed, 3 insertions(
yd
Signed-off-by: Miroslav Lichvar
---
tools/testing/selftests/timers/freq-step.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/timers/freq-step.c
b/tools/testing/selftests/timers/freq-step.c
index 14a2b77fd012..cd094b49819f 100644
--- a/too
Commit-ID: 78b98e3c5a66d569a53b8f57b6a698f912794a43
Gitweb: https://git.kernel.org/tip/78b98e3c5a66d569a53b8f57b6a698f912794a43
Author: Miroslav Lichvar <mlich...@redhat.com>
AuthorDate: Fri, 9 Mar 2018 10:42:48 -0800
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Sat,
Commit-ID: 78b98e3c5a66d569a53b8f57b6a698f912794a43
Gitweb: https://git.kernel.org/tip/78b98e3c5a66d569a53b8f57b6a698f912794a43
Author: Miroslav Lichvar
AuthorDate: Fri, 9 Mar 2018 10:42:48 -0800
Committer: Ingo Molnar
CommitDate: Sat, 10 Mar 2018 09:12:41 +0100
timekeeping/ntp
Commit-ID: c2cda2a5bda9f1369c9d1ab54a20571c13cf2743
Gitweb: https://git.kernel.org/tip/c2cda2a5bda9f1369c9d1ab54a20571c13cf2743
Author: Miroslav Lichvar <mlich...@redhat.com>
AuthorDate: Fri, 9 Mar 2018 10:42:47 -0800
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Sat,
Commit-ID: c2cda2a5bda9f1369c9d1ab54a20571c13cf2743
Gitweb: https://git.kernel.org/tip/c2cda2a5bda9f1369c9d1ab54a20571c13cf2743
Author: Miroslav Lichvar
AuthorDate: Fri, 9 Mar 2018 10:42:47 -0800
Committer: Ingo Molnar
CommitDate: Sat, 10 Mar 2018 09:12:41 +0100
timekeeping/ntp: Don't
5 [OK]
10 +0.000 3 12 +0.000 4 11 [OK]
Miroslav Lichvar (2):
timekeeping: Don't align frequency adjustments to ticks
timekeeping: Determine multiplier directly from NTP tick length
include/linux/timekeeper_internal.h | 2 +
kernel/time/timekeepin
5 [OK]
10 +0.000 3 12 +0.000 4 11 [OK]
Miroslav Lichvar (2):
timekeeping: Don't align frequency adjustments to ticks
timekeeping: Determine multiplier directly from NTP tick length
include/linux/timekeeper_internal.h | 2 +
kernel/time/timekeepin
the point where the frequency is
effectively changed at the time of the update. This removes a major
source of the NTP error.
Cc: John Stultz <john.stu...@linaro.org>
Cc: Prarit Bhargava <pra...@redhat.com>
Cc: Richard Cochran <richardcoch...@gmail.com>
Signed-off-by: Miros
<john.stu...@linaro.org>
Cc: Prarit Bhargava <pra...@redhat.com>
Cc: Richard Cochran <richardcoch...@gmail.com>
Signed-off-by: Miroslav Lichvar <mlich...@redhat.com>
---
include/linux/timekeeper_internal.h | 2 +
kernel/time/timekeeping.c | 138 -
the point where the frequency is
effectively changed at the time of the update. This removes a major
source of the NTP error.
Cc: John Stultz
Cc: Prarit Bhargava
Cc: Richard Cochran
Signed-off-by: Miroslav Lichvar
---
kernel/time/timekeeping.c | 3 ---
1 file changed, 3 deletions(-)
diff
: Prarit Bhargava
Cc: Richard Cochran
Signed-off-by: Miroslav Lichvar
---
include/linux/timekeeper_internal.h | 2 +
kernel/time/timekeeping.c | 138
2 files changed, 49 insertions(+), 91 deletions(-)
diff --git a/include/linux/timekeeper_internal.h
000 3 12 +0.000 4 11 [OK]
Miroslav Lichvar (2):
timekeeping: Don't align frequency adjustments to ticks
timekeeping: Determine multiplier directly from NTP tick length
include/linux/timekeeper_internal.h | 2 +
kernel/time/timekeeping.c |
000 3 12 +0.000 4 11 [OK]
Miroslav Lichvar (2):
timekeeping: Don't align frequency adjustments to ticks
timekeeping: Determine multiplier directly from NTP tick length
include/linux/timekeeper_internal.h | 2 +
kernel/time/timekeeping.c |
Commit-ID: aea3706cfc4d952ed6d32b6d5845b5ecd99ed7f5
Gitweb: https://git.kernel.org/tip/aea3706cfc4d952ed6d32b6d5845b5ecd99ed7f5
Author: Miroslav Lichvar <mlich...@redhat.com>
AuthorDate: Mon, 13 Nov 2017 14:51:31 -0800
Committer: Thomas Gleixner <t...@linutronix.de>
CommitD
Commit-ID: aea3706cfc4d952ed6d32b6d5845b5ecd99ed7f5
Gitweb: https://git.kernel.org/tip/aea3706cfc4d952ed6d32b6d5845b5ecd99ed7f5
Author: Miroslav Lichvar
AuthorDate: Mon, 13 Nov 2017 14:51:31 -0800
Committer: Thomas Gleixner
CommitDate: Tue, 14 Nov 2017 11:20:25 +0100
timekeeping
all, and not at all seems slightly better in my mind.
Yeah, controlling the clock in such conditions will be difficult. The
kernel/ntp PLL requires periodic updates. There is some code in
ntp_update_offset() that reduces the frequency adjustment when PLL
updates are missing, but I'm not actually sure if it works correctly
with suspend.
--
Miroslav Lichvar
eems slightly better in my mind.
Yeah, controlling the clock in such conditions will be difficult. The
kernel/ntp PLL requires periodic updates. There is some code in
ntp_update_offset() that reduces the frequency adjustment when PLL
updates are missing, but I'm not actually sure if it works correctly
with suspend.
--
Miroslav Lichvar
240 |
>
> Using so_txtime, the peak to peak jitter is about 100 nanoseconds,
Nice!
--
Miroslav Lichvar
240 |
>
> Using so_txtime, the peak to peak jitter is about 100 nanoseconds,
Nice!
--
Miroslav Lichvar
gc, char **argv)
> ksft_exit_fail();
>
> ksft_exit_pass();
> +
> + return 0;
> }
It seems most tests use "return ksft_exit_pass();". Would that be
preferred over separate return? I don't have a preference.
Both patches in this set look good to me.
Thanks,
--
Miroslav Lichvar
gc, char **argv)
> ksft_exit_fail();
>
> ksft_exit_pass();
> +
> + return 0;
> }
It seems most tests use "return ksft_exit_pass();". Would that be
preferred over separate return? I don't have a preference.
Both patches in this set look good to me.
Thanks,
--
Miroslav Lichvar
d init_test(void)
>
> if (precision > MAX_PRECISION) {
> printf("[SKIP]\n");
> - ksft_exit_skip();
> + ksft_exit_skip("[SKIP]\n");
To avoid printing "skip" multiple times, I'd suggest to change the
argument of ksft_exit_skip to NULL.
Thanks,
--
Miroslav Lichvar
d init_test(void)
>
> if (precision > MAX_PRECISION) {
> printf("[SKIP]\n");
> - ksft_exit_skip();
> + ksft_exit_skip("[SKIP]\n");
To avoid printing "skip" multiple times, I'd suggest to change the
argument of ksft_exit_skip to NULL.
Thanks,
--
Miroslav Lichvar
Prarit Bhargava <pra...@redhat.com>
Cc: Richard Cochran <richardcoch...@gmail.com>
Signed-off-by: Miroslav Lichvar <mlich...@redhat.com>
---
tools/testing/selftests/timers/inconsistency-check.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/
Cochran
Signed-off-by: Miroslav Lichvar
---
tools/testing/selftests/timers/inconsistency-check.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/timers/inconsistency-check.c
b/tools/testing/selftests/timers/inconsistency-check.c
index caf1bc9
or in-kernel users.
The patch looks good to me and in testing on x86_64 I didn't see any
issues with the CLOCK_MONOTONIC_RAW clock.
Thanks,
--
Miroslav Lichvar
or in-kernel users.
The patch looks good to me and in testing on x86_64 I didn't see any
issues with the CLOCK_MONOTONIC_RAW clock.
Thanks,
--
Miroslav Lichvar
exceed specified limits.
Cc: John Stultz <john.stu...@linaro.org>
Cc: Richard Cochran <richardcoch...@gmail.com>
Cc: Prarit Bhargava <pra...@redhat.com>
Signed-off-by: Miroslav Lichvar <mlich...@redhat.com>
---
tools/testing/selftests/timers/Makefile| 5 +-
tools/testi
exceed specified limits.
Cc: John Stultz
Cc: Richard Cochran
Cc: Prarit Bhargava
Signed-off-by: Miroslav Lichvar
---
tools/testing/selftests/timers/Makefile| 5 +-
tools/testing/selftests/timers/freq-step.c | 268 +
2 files changed, 271 insertions(+), 2 deletions
On Fri, May 19, 2017 at 05:35:38PM -0700, John Stultz wrote:
> >> On Wed, May 17, 2017 at 10:22 AM, Miroslav Lichvar <mlich...@redhat.com>
> >> wrote:
> >> > Is there a better way to run the timekeeping code in an userspace
> >> > application?
On Fri, May 19, 2017 at 05:35:38PM -0700, John Stultz wrote:
> >> On Wed, May 17, 2017 at 10:22 AM, Miroslav Lichvar
> >> wrote:
> >> > Is there a better way to run the timekeeping code in an userspace
> >> > application? I suspect it would need some
On Wed, May 17, 2017 at 10:02:00AM -0700, John Stultz wrote:
> On Wed, May 17, 2017 at 9:57 AM, Miroslav Lichvar <mlich...@redhat.com> wrote:
> > On Wed, May 17, 2017 at 09:30:31AM -0700, John Stultz wrote:
> >> Could you submit your linux-tktest infrastructure to the kself
On Wed, May 17, 2017 at 10:02:00AM -0700, John Stultz wrote:
> On Wed, May 17, 2017 at 9:57 AM, Miroslav Lichvar wrote:
> > On Wed, May 17, 2017 at 09:30:31AM -0700, John Stultz wrote:
> >> Could you submit your linux-tktest infrastructure to the kselftests dir?
> >
&g
that breaks frequently as the timekeeping and
other kernel code changes. Are you sure you want that in the kernel
tree? :)
--
Miroslav Lichvar
that breaks frequently as the timekeeping and
other kernel code changes. Are you sure you want that in the kernel
tree? :)
--
Miroslav Lichvar
As the last users of CONFIG_GENERIC_TIME_VSYSCALL_OLD have been updated,
the support can be removed from the timekeeping code.
Cc: John Stultz <john.stu...@linaro.org>
Cc: Prarit Bhargava <pra...@redhat.com>
Cc: Richard Cochran <richardcoch...@gmail.com>
Signed-off-by: Miros
As the last users of CONFIG_GENERIC_TIME_VSYSCALL_OLD have been updated,
the support can be removed from the timekeeping code.
Cc: John Stultz
Cc: Prarit Bhargava
Cc: Richard Cochran
Signed-off-by: Miroslav Lichvar
---
include/linux/timekeeper_internal.h | 7 --
kernel/time/Kconfig
to keep the point where the frequency is
effectively changed at the time of the update. This removes a major
source of the NTP error.
Cc: John Stultz <john.stu...@linaro.org>
Cc: Prarit Bhargava <pra...@redhat.com>
Cc: Richard Cochran <richardcoch...@gmail.com>
Signed-off-by: Miros
to keep the point where the frequency is
effectively changed at the time of the update. This removes a major
source of the NTP error.
Cc: John Stultz
Cc: Prarit Bhargava
Cc: Richard Cochran
Signed-off-by: Miroslav Lichvar
---
kernel/time/timekeeping.c | 3 ---
1 file changed, 3 deletions(-)
diff
0.0 0.2 0.6
30.0 0.3 0.6 0.0 0.2 0.6
10 0.0 0.3 0.6 0.0 0.2 0.6
Miroslav Lichvar (3):
timekeeping: Remove support for old vsyscalls
timekeeping: Don't align frequency adjustments to ticks
0.0 0.2 0.6
30.0 0.3 0.6 0.0 0.2 0.6
10 0.0 0.3 0.6 0.0 0.2 0.6
Miroslav Lichvar (3):
timekeeping: Remove support for old vsyscalls
timekeeping: Don't align frequency adjustments to ticks
<john.stu...@linaro.org>
Cc: Prarit Bhargava <pra...@redhat.com>
Cc: Richard Cochran <richardcoch...@gmail.com>
Signed-off-by: Miroslav Lichvar <mlich...@redhat.com>
---
include/linux/timekeeper_internal.h | 2 +
kernel/time/timekeeping.c | 137 -
: Prarit Bhargava
Cc: Richard Cochran
Signed-off-by: Miroslav Lichvar
---
include/linux/timekeeper_internal.h | 2 +
kernel/time/timekeeping.c | 137
2 files changed, 48 insertions(+), 91 deletions(-)
diff --git a/include/linux/timekeeper_internal.h
On Fri, May 12, 2017 at 10:26:12AM -0700, John Stultz wrote:
> On Fri, May 12, 2017 at 8:14 AM, Miroslav Lichvar <mlich...@redhat.com> wrote:
> > I see this with real PHCs and PTP/NTP synchronization too. It's very
> > confusing when the timekeeping changes so much f
On Fri, May 12, 2017 at 10:26:12AM -0700, John Stultz wrote:
> On Fri, May 12, 2017 at 8:14 AM, Miroslav Lichvar wrote:
> > I see this with real PHCs and PTP/NTP synchronization too. It's very
> > confusing when the timekeeping changes so much for no apparent reason.
> &g
On Tue, Jul 15, 2014 at 09:02:38PM -0700, John Stultz wrote:
> On 07/08/2014 04:08 AM, Miroslav Lichvar wrote:
> > I spent some time trying to figure out a workaround for the nanosecond
> > rounding, but I didn't find anything that wouldn't complicate the mult
> > adjustment
On Tue, Jul 15, 2014 at 09:02:38PM -0700, John Stultz wrote:
> On 07/08/2014 04:08 AM, Miroslav Lichvar wrote:
> > I spent some time trying to figure out a workaround for the nanosecond
> > rounding, but I didn't find anything that wouldn't complicate the mult
> > adjustment
option to not use the PRECISE ioctl even if it's supported.
--
Miroslav Lichvar
option to not use the PRECISE ioctl even if it's supported.
--
Miroslav Lichvar
1 - 100 of 188 matches
Mail list logo
