Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1466477
| From | Steven Rostedt <rostedt@goodmis.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2 0/4] tracing: Add Hardware Latency detector tracer |
| Date | 2016-08-19 17:00 +0200 |
| Message-ID | <s7Tr4-6UW-15@gated-at.bofh.it> (permalink) |
| References | <s4GTn-n4-1@gated-at.bofh.it> <s7SEF-6Cv-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, 19 Aug 2016 16:09:28 +0200
Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, Aug 10, 2016 at 09:53:56AM -0400, Steven Rostedt wrote:
> > Changes since v1:
> >
> > . Added checks for CONFIG_GENERIC_SCHED_CLOCK, and if that is set,
> > only nmi_counts will be recorded when an NMI is triggered, but not
> > the time in NMI, because the generic sched_clock is not NMI safe.
> > (suggested by Sebastian Andrzej Siewior)
>
> So any of the platforms using GENERIC_SCHED_CLOCK _have_ NMIs ?
From what I gather, the answer is no, so I don't think this is an issue.
>
> In any case, for those you could probably use ktime_get_mono_fast_ns().
Is that safe to call from NMI? Looking into the code I see:
now = ktime_to_ns(tkr->base) + timekeeping_get_ns(tkr);
where timekeeping_get_ns() has:
timekeeping_get_delta()
which does:
read_seqcount_begin()
which has (eventually):
repeat:
ret = READ_ONCE(s->sequence);
if (unlikely(ret & 1)) {
cpu_relax();
goto repeat;
}
return ret;
Which I think could cause a deadlock from an NMI.
-- Steve
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH v2 0/4] tracing: Add Hardware Latency detector tracer Peter Zijlstra <peterz@infradead.org> - 2016-08-19 16:10 +0200
Re: [PATCH v2 0/4] tracing: Add Hardware Latency detector tracer Steven Rostedt <rostedt@goodmis.org> - 2016-08-19 17:00 +0200
Re: [PATCH v2 0/4] tracing: Add Hardware Latency detector tracer Peter Zijlstra <peterz@infradead.org> - 2016-08-19 17:10 +0200
Re: [PATCH v2 0/4] tracing: Add Hardware Latency detector tracer John Stultz <john.stultz@linaro.org> - 2016-08-19 18:40 +0200
Re: [PATCH v2 0/4] tracing: Add Hardware Latency detector tracer Thomas Gleixner <tglx@linutronix.de> - 2016-08-23 11:00 +0200
Re: [PATCH v2 0/4] tracing: Add Hardware Latency detector tracer Peter Zijlstra <peterz@infradead.org> - 2016-08-23 11:50 +0200
csiph-web