Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1464612

Re: [RFC] ftrace / perf 'recursion'

From Peter Zijlstra <peterz@infradead.org>
Newsgroups linux.kernel
Subject Re: [RFC] ftrace / perf 'recursion'
Date 2016-08-17 17:00 +0200
Message-ID <s7atY-2oK-5@gated-at.bofh.it> (permalink)
References (1 earlier) <s76qm-8dD-45@gated-at.bofh.it> <s76JH-8kQ-1@gated-at.bofh.it> <s79oe-1IE-23@gated-at.bofh.it> <s79Hz-25o-17@gated-at.bofh.it> <s7a0W-2dr-25@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, Aug 17, 2016 at 10:25:59AM -0400, Steven Rostedt wrote:

> > > Also, it will prevent any tracing of NMIs that occur in there.  
> > 
> > It should not, see how I only mark the IRQ bit, not the NMI bit.
> 
> Ah, I didn't look deep at what you set there. Maybe that would work.
> Still pretty hacky.

Sure :-)

> > > I would really like to keep this fix within perf if possible. If
> > > anything, the flag should just tell the perf function handler not to
> > > trace, this shouldn't stop all function handlers.  
> > 
> > Well, my thinking was that there's a reason most of irq_work is already
> > notrace. kernel/irq_work.c has CC_FLAGS_FTRACE removed. That seems to
> > suggest that tracing irq_work is a problem.
> 
> Well, you were the one that added that ;-)

OK, I suppose I can do the same for perf only, which is basically the
first patch on this thread. And then remove the notrace muck for
irq_work.c.

> Are you calling a signal to userspace via the irq work? Maybe we should
> have a kernel thread that does that instead. That way, the irq works
> can be suspended until the kernel thread gets to run. Then even though
> the waking of the thread will cause more events, it will be spaced out
> enough not to cause an irq work storm.

Nah, that'd wreck the desired semantics. We could maybe use a task_work
for the signal cruft though, and only generate the signal on the return
to userspace. But I'm not sure that will cure the problem.

We'd still need the irq_work to wake tasks stuck in poll() and friends.
And once we're over the watermark, every new event will trigger that
wakeup, and the wakeup will generate a new event etc..

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC] ftrace / perf 'recursion' Peter Zijlstra <peterz@infradead.org> - 2016-08-17 11:30 +0200
  Re: [RFC] ftrace / perf 'recursion' Peter Zijlstra <peterz@infradead.org> - 2016-08-17 12:40 +0200
    Re: [RFC] ftrace / perf 'recursion' Peter Zijlstra <peterz@infradead.org> - 2016-08-17 13:00 +0200
      Re: [RFC] ftrace / perf 'recursion' Steven Rostedt <rostedt@goodmis.org> - 2016-08-17 15:50 +0200
        Re: [RFC] ftrace / perf 'recursion' Peter Zijlstra <peterz@infradead.org> - 2016-08-17 16:10 +0200
          Re: [RFC] ftrace / perf 'recursion' Steven Rostedt <rostedt@goodmis.org> - 2016-08-17 16:30 +0200
            Re: [RFC] ftrace / perf 'recursion' Peter Zijlstra <peterz@infradead.org> - 2016-08-17 17:00 +0200
              Re: [RFC] ftrace / perf 'recursion' Steven Rostedt <rostedt@goodmis.org> - 2016-08-17 17:10 +0200

csiph-web