There are occasional very very long (30..60 sec) delays happening when calling
gettimeofday() vsyscall on x86_64 with 2.6.14-rt22 kernel.
These delays come from while() looping over invalid data that are
going to be discarded by seqlock.
arch/x86_64/kernel/vsyscall.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
Index: linux/arch/x86_64/kernel/vsyscall.c
===================================================================
--- linux.orig/arch/x86_64/kernel/vsyscall.c
+++ linux/arch/x86_64/kernel/vsyscall.c
@@ -111,14 +111,15 @@ static force_inline void do_vgettimeofda
/* add nsec offset to wall_time_tv */
*tv = __vsyscall_gtod_data.wall_time_tv;
- do_div(nsec_delta, NSEC_PER_USEC);
- tv->tv_usec += (unsigned long) nsec_delta;
-
- while (tv->tv_usec > USEC_PER_SEC) {
- tv->tv_sec += 1;
- tv->tv_usec -= USEC_PER_SEC;
- }
} while (read_seqretry(&__vsyscall_gtod_lock, seq));
+
+ do_div(nsec_delta, NSEC_PER_USEC);
+ tv->tv_usec += (unsigned long) nsec_delta;
+
+ while (tv->tv_usec > USEC_PER_SEC) {
+ tv->tv_sec += 1;
+ tv->tv_usec -= USEC_PER_SEC;
+ }
}
/*
On Fri, 2005-12-09 at 22:38 +0300, Serge Belyshev wrote:
>
> There are occasional very very long (30..60 sec) delays happening when calling
> gettimeofday() vsyscall on x86_64 with 2.6.14-rt22 kernel.
>
> These delays come from while() looping over invalid data that are
> going to be discarded by seqlock.
Ah, good catch! I just included a similar change (moved all the math
outside the lock) in my own tree.
Thanks for finding this!
-john
On Fri, 2005-12-09 at 18:33 -0800, john stultz wrote:
> On Fri, 2005-12-09 at 22:38 +0300, Serge Belyshev wrote:
> >
> > There are occasional very very long (30..60 sec) delays happening when calling
> > gettimeofday() vsyscall on x86_64 with 2.6.14-rt22 kernel.
> >
> > These delays come from while() looping over invalid data that are
> > going to be discarded by seqlock.
>
> Ah, good catch! I just included a similar change (moved all the math
> outside the lock) in my own tree.
Is there something equivalent on i386 or this is just an x86_64 thing?
Over the past few days I have seen temporary "lockups" of my machine
(athlon X2 running -2.6.14-rt22, PREEMPT_RT, no hi res timers) lasting
for, say between 10 and 30 seconds. This happens maybe one to three
times in a day (that I noticed). The symptom is that the mouse moves but
everything else is just not doing anything. I don't see anything in the
logs or dmesg after the freeze, or on the servers that machine depends
on (through nfs). During one of those lockups a system load monitor in
the gnome panel was visible and it looked like there was a 100% system
load (or close) in one of the cpus.
-- Fernando