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 backward time drift > when isr comes between reading tsc register and returning the value. > This drifting time differs based on the number of isr handled and the > time taken to service each isr. This is not a drift. Please do not misuse technical expressions which have a well defined meaning. rdtsc() val = read() interrupt .... return val Time does not go backwards in that case simply because at the point it was taken it was correct. Versus that timerfd problem this situaiton is completely irrelevant simply because hrtimer_forward_now() happens _AFTER_ the timer was expired not before. So the read of CLOCK_MONOTONIC in hrtimer_forward_now() is _AFTER_ the read of CLOCK_MONOTONIC in hrtimer_interrupt() which expires the timer and there are only two issue which can make that read in hrtimer_forward_now() go backwards vs. the time which was read when the timer was expired: 1) TSCs are out of sync or affected otherwise 2) Timekeeping has a bug. That's where the problem lies it needs to be analyzed whether this is caused by #1 or by #2. Once we know that we can discuss solutions. > Agreed. Our intention is not to put a workaround. Intention is to > write a reliable application that handles all values returned by a > system call. > At present, the application doesn't know whether 0 return value is a > bug or valid case. Again, you are tackling the wrong end. You need to find, analyze and fix the root cause. > > Is the timer expiry and the timerfd_read() on the same CPU or on different > > ones? > > We don't have data to answer this. However, the kernel is configured > to allow timer migration. > So, we believe, the timer expiry and timerfd_read happens on different CPUs. Believe is a matter of religion and pretty useless to analyze technical problems. It's not rocket science to figure this out with tracing. > > Can you please provide a full dmesg from boot to after the point where this > > failure happens? > > We don't see any logs in dmesg during the occurrence of this problem. > We may not be able to share complete dmesg logs due to security reasons. > We haven't seen any time drifting related messages too. > Let us know, if you are looking for any specific log message. I was asking for a full boot log for a reason. Is it impossible to stick that into a mail? Thanks, tglx
