Arul,
On Fri, 6 Sep 2019, Arul Jeniston wrote:
> >Changing the return value to 1 would be just a cosmetic workaround.
>
> Agreed. Returning 1 is incorrect as It causes the next read() to
> return before the interval time passed.
>
> >So I rather change the documentation (this applies only to CLO
Hi tglx,
>Changing the return value to 1 would be just a cosmetic workaround.
Agreed. Returning 1 is incorrect as It causes the next read() to
return before the interval time passed.
>So I rather change the documentation (this applies only to CLOCK_REALTIME
>and CLOCK_REALTIME_ALARM) and explain
Arul,
On Thu, 5 Sep 2019, Arul Jeniston wrote:
> When we adjust the date setting using date command we observed
> 'timerfd_read()' on CLOCK_REALTIME (TFD_TIMER_ABSTIME flag is set)
> returns 0.
> we don't see any hardware influence here and we are able to recreate
> it consistently. Is it expected
hi Tglx,
When we adjust the date setting using date command we observed
'timerfd_read()' on CLOCK_REALTIME (TFD_TIMER_ABSTIME flag is set)
returns 0.
we don't see any hardware influence here and we are able to recreate
it consistently. Is it expected? if yes, isn't it something to be
documented in
Hi Tglx,
> Can you please boot something more recent - at least 4.19 LTS - on that
> machine and let it run for a couple of days to check whether there are 'TSC
> ADJUST' related entries in dmesg?
Sure. Would check and update.
Regards,
Arul
Arul,
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Tue, 20 Aug
hi Tglx
Agreed. Please find the dmesg output below. We see the problem on
[1456773.366951].
Let us know if you find anything suspicious.
[0.00] Linux version 4.9.0-8-amd64
(debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian
6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.110-3+deb9
Arul,
On Mon, 19 Aug 2019, Arul Jeniston wrote:
> > hits ktime_get() or whether it happens concurrent on a different CPU.
> > ktime_get() can never use inconsistent tk data for calculating the time.
>
> Agreed. I think, I am not making my point clear here.
> Do you mean to say ktime_get() would
On Mon, 19 Aug 2019, Arul Jeniston wrote:
> hi Tglx,
> > But for the above scenario:
> >
> > ktime_get()
> > do {
> > seq = read_seqcount_begin(&tk_core.seq);
> > base = tk->tkr_mono.base;
> > nsecs = timekeeping_get_ns(&tk->tkr_mono);
> >
>
hi Tglx,
> But for the above scenario:
>
> ktime_get()
> do {
> seq = read_seqcount_begin(&tk_core.seq);
> base = tk->tkr_mono.base;
> nsecs = timekeeping_get_ns(&tk->tkr_mono);
>
> } while (read_seqcount_retry(&tk_core.seq, seq));
>
>
Arul,
On Mon, 19 Aug 2019, Arul Jeniston wrote:
> > 1) TSCs are out of sync or affected otherwise
>
> If the TSC clock is unstable and not synchronized, Linux kernel throws
> dmesg logs and changes the current clock source to next best timer
> (hpet). But we didn't see these logs in any of the
hi Tglx,
...
> > > Is the timer expiry and the timerfd_read() on the same CPU or on different
> > > ones?
> >
We have 1+ units running in production. We see this problem ~20
switches in a span of one year time.
The problem is not seen more than once in the same unit. The
occurrence is random
Arul,
On Mon, 19 Aug 2019, Arul Jeniston wrote:
> During normal run, we do see small amount (~1000 cycles) of backward
> time drifts one in a while.
> This is likely happens due to the race between multiple processors and
> ISR routines.
No.
> We have added a hook to read_tsc() and observed back
Hi tgls,
> BIOS is the more likely candidate.
We would check BIOS and update.
> We expect TSC not to go backwards. If it does it's broken and not usable as
> a clocksource for the kernel. The problem is that this is not necessarily
> easy to detect.
We used relative timer with CLOCK_REALTIME
Arul,
On Sat, 17 Aug 2019, Arul Jeniston wrote:
> Do you agree the possibility of returning zero value from timerfd_read()?
Obviosuly it happens.
> > That has absolutely nothing to do with CLOCK_REALTIME. Your machines
> > TSC is either going backwards or not synchronized between cores.
> >
>
Arul,
On Fri, 16 Aug 2019, Arul Jeniston wrote:
> Adding few more data points...
Can you please trim your replies? It's annoying to have to search for the
meat of your mail by scrolling down several pages and paying attention to
not skip something useful inside of useless information.
> On Fri,
> On Fri, 16 Aug 2019, Arul Jeniston wrote:
> >
> > > Subject: [PATCH] FS: timerfd: Fix unexpected return value of timerfd_read
> > > function.
> >
> > The prefix is not 'FS: timerfd:'
> >
> > 1) The usual prefix for fs/* is: 'fs:' but.
Hi tglx,
Thank you for your comments.
Please find my commend in-lined
On Fri, Aug 16, 2019 at 4:15 PM Thomas Gleixner wrote:
>
> Arul,
>
> On Fri, 16 Aug 2019, Arul Jeniston wrote:
>
> > Subject: [PATCH] FS: timerfd: Fix unexpected return value of timerfd_read
> >
Arul,
On Fri, 16 Aug 2019, Arul Jeniston wrote:
> Subject: [PATCH] FS: timerfd: Fix unexpected return value of timerfd_read
> function.
The prefix is not 'FS: timerfd:'
1) The usual prefix for fs/* is: 'fs:' but...
2) git log fs/timerfd.c gives you a pretty good hin
'hrtimer_forward_now()' returns zero due to bigger backward time drift.
This causes timerfd_read to return 0. As per man page, read on timerfd
is not expected to return 0.
This problem is well explained in https://lkml.org/lkml/2019/7/31/442
. This patch fixes this problem.
Signed-off-by: Arul Jen
From: ARUL JENISTON MC
---
fs/timerfd.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/fs/timerfd.c b/fs/timerfd.c
index 6a6fc8aa1de7..f5094e070e9a 100644
--- a/fs/timerfd.c
+++ b/fs/timerfd.c
@@ -284,8 +284,16 @@ static ssize_t timerfd_read(struct file *file,
21 matches
Mail list logo
