lkml.org 
[lkml]   [2011]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 3/6] trace: Add tracepoints to IRQ work run handler
On Thu, Jul 28, 2011 at 03:49:21PM +0200, Peter Zijlstra wrote:
> On Thu, 2011-07-28 at 15:29 +0200, Frederic Weisbecker wrote:
> > On Thu, Jul 28, 2011 at 02:12:51PM +0200, Peter Zijlstra wrote:
> > > On Wed, 2011-07-27 at 11:57 -0700, Vaibhav Nagarnaik wrote:
> > > > @@ -122,6 +123,7 @@ void irq_work_run(void)
> > > > {
> > > > struct irq_work *list;
> > > >
> > > > trace_irq_work_run_entry(0);
> > > > if (this_cpu_read(irq_work_list) == NULL)
> > > > return;
> > > >
> > > > @@ -149,6 +151,7 @@ void irq_work_run(void)
> > > > next_flags(NULL, IRQ_WORK_BUSY),
> > > > NULL);
> > > > }
> > > > + trace_irq_work_run_exit(0);
> > > > }
> > > > EXPORT_SYMBOL_GPL(irq_work_run);
> > >
> > > So what happens when we call irq_work_run() from the timer interrupt?
> > >
> >
> > We probably need something like:
> >
> > void irq_work_run_interrupt(void)
> > {
> > trace_irq_work_run_entry(0);
> > irq_work_run();
> > trace_irq_work_run_exit(0);
> > }
>
> No we don't. That lives in arch code and its up to the arch to decide
> where, when and how to call that.
>
> On PPC for example that's hooked of the timer interrupt.
>
> See here again your 'generalization' crap breaks down.

Yeah, you're right.

I don't know very well other archs than x86 and probably did the
mistake to generalize too much on top of its irq layout.

Probably they should revert to something closer to the first iterations of that patchset.

Now I'm going to let Vaibhav and David choose whichever weapon they want to stab me if
we meet up one day. Just not going to stay in a floor next to them with nobody
around.


\
 
 \ /
  Last update: 2011-07-28 16:07    [W:0.052 / U:0.488 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site