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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to