Messages in this thread | | | Date | Fri, 19 Dec 2014 15:36:45 -0500 | From | Dave Jones <> | Subject | Re: frequent lockups in 3.18rc4 |
| |
On Fri, Dec 19, 2014 at 03:31:36PM -0500, Chris Mason wrote:
> > So it's not stuck *inside* read_hpet(), and it's almost certainly not > > the loop over the sequence counter in ktime_get() either (it's not > > increasing *that* quickly). But some basically infinite __run_hrtimer > > thing or something? > > Really interesting. > > So, we're calling __run_hrtimer in a loop: > > while ((node = timerqueue_getnext(&base->active))) { > ... > __run_hrtimer(timer, &basenow); > ... > } > > The easy question is how often does trinity call nanosleep?
It shouldn't call it directly. (syscalls/nanosleep.c)
/* * SYSCALL_DEFINE2(nanosleep, struct timespec __user *, rqtp, struct timespec __user *, rmtp) */ #include "sanitise.h"
struct syscallentry syscall_nanosleep = { .name = "nanosleep", .num_args = 2, .arg1name = "rqtp", .arg1type = ARG_ADDRESS, .arg2name = "rmtp", .arg2type = ARG_ADDRESS, .flags = AVOID_SYSCALL, // Boring. Can cause long sleeps. };
That last line being the key one. We used to do it, but it's well.. boring. We could do something smarter, but given it's never triggered anything interesting in the past, focussing runtime on the more interesting syscalls seems to have been more fruitful.
Dave
| |