[ltt-dev] [patch 3/9] LTTng instrumentation tasklets

Chetan.Loke at Emulex.Com Chetan.Loke at Emulex.Com
Wed Mar 25 09:52:32 EDT 2009


 

> -----Original Message-----
> From: linux-kernel-owner at vger.kernel.org 
> [mailto:linux-kernel-owner at vger.kernel.org] On Behalf Of Ingo Molnar
> Sent: Tuesday, March 24, 2009 1:56 PM
> To: Mathieu Desnoyers
> Cc: akpm at linux-foundation.org; linux-kernel at vger.kernel.org; 
> ltt-dev at lists.casi.polymtl.ca; Frederic Weisbecker; Jason 
> Baron; Peter Zijlstra; Thomas Gleixner; Russell King; Masami 
> Hiramatsu; Frank Ch. Eigler; Hideo AOKI; Takashi Nishiie; 
> Steven Rostedt; Eduard - Gabriel Munteanu
> Subject: Re: [patch 3/9] LTTng instrumentation tasklets
> 
> 
> * Mathieu Desnoyers <mathieu.desnoyers at polymtl.ca> wrote:
> 
> > tasklet entry and exit events.
> 
> > +DEFINE_TRACE(irq_tasklet_high_entry);
> > +DEFINE_TRACE(irq_tasklet_high_exit);
> > +DEFINE_TRACE(irq_tasklet_low_entry);
> > +DEFINE_TRACE(irq_tasklet_low_exit);
> 
> Dunno - tasklets are a legacy mechanism, not sure we want to 
> instrument them. 


Quick question. I understand this is unrelated to this patch. So I apologize in advance.
Ingo - you mentioned "tasklets are a legacy mechanism". Is there a plan to phase them out ? Let me draw a small picture as to what's bothering me.

With the SR-IOV support if there are 'N' virtual functions then there will be 'N' driver instances(actually N+1, 1 for the PF). If that driver drains the responses in the interrupt context then all such VF-instances could virtually block everyone else(because SR-IOV guys might also have MSI-X enabled).
So now all such drivers should alter their Rx path.Driver's can queue tasklets and can also get the performance they want.

Any suggestions?

thanks
Chetan



More information about the lttng-dev mailing list