Did you tried ftrace? https://www.kernel.org/doc/Documentation/trace/ftrace.txt I've been using this to measure some latencies. The problem here is visualizing the output. If you need someting more elaborated than simple prints with timestamps and delta calculations, then you should try something more complex. If not you can enable FTRACE and generate trace output with delta timestamps on it, event for interrupts :) Best regards, 2016-08-01 7:32 GMT-03:00 Muni Sekhar <munisekharrms@xxxxxxxxx>: > On Fri, Jul 29, 2016 at 9:05 PM, Daniel. <danielhilst@xxxxxxxxx> wrote: >> Nice tool @Ricardo! >> >> 2016-07-29 10:48 GMT-03:00 Ricardo Ribalda Delgado <ricardo.ribalda@xxxxxxxxx>: >>> you can use http://lttng.org/ for analyzing this > Thanks Ricardo, I will use this. > >>> >>> Regards! >>> >>> On Fri, Jul 29, 2016 at 12:44 PM, Pranay Srivastava <pranjas@xxxxxxxxx> wrote: >>>> On Fri, Jul 29, 2016 at 4:02 PM, Muni Sekhar <munisekharrms@xxxxxxxxx> wrote: >>>>> Hi All, >>>>> >>>>> I have a doubt regarding the workqueue scheduling. >>>>> >>>>> I am using the workqueue for processing the Rx Interrupt data. I am >>>>> calling schedule_work() on receiving the Rx interrupt from hardware. >>>>> >>>>> I calculated the time between calling the schedule_work() and >>>>> workqueue task actually getting executed, Here I see many cases of >>>>> less than 100 us(It is fairly good). >>>>> >>>>> But sometimes I see 10’s of ms and a lot in the 100’s of ms. I have >>>>> seen over 0.5 secs too. I would like to know why does sometimes kernel >>>>> takes longer time(in milli seconds) to schedule it? Is there any way >>>>> to reduce this time gap? >>>>> >>>>> >>>>> My code: >>>>> >>>>> static void my_workqueuetask(struct work_struct *work) >>>>> { >>>>> printk("In %s() \n",__func__); >>>>> >>>> You probably don't need this if it's just for your work_fn, yeah but >>>> if there's race between this and something else... >>>>> mutex_lock(&bh_mutex); >>>>> >>>>> //Do something here >>>>> >>>>> mutex_unlock(&bh_mutex); >>>>> } >>>>> >>>>> >>>>> static irqreturn_t my_irq_handler(int irq, void *dev) >>>>> { >>>>> ……; >>>>> >>>>> if(Rx Interrupt) >>>>> schedule_work(&rx_work); >>>> >>>> Maybe system_wq has too much already on it's plate? >>>> Have you tried the same with completion and a kthread? or >>>> with your own workqueue, overkill but you can give it a shot. > I have not tried this. First I will analyze with lttng and then > attempts this. Does using our own workqueue reduces the latency? > >>>>> >>>>> return IRQ_HANDLED; >>>>> } >>>>> >>>>> -- >>>>> Thanks, >>>>> Sekhar >>>>> >>>>> _______________________________________________ >>>>> Kernelnewbies mailing list >>>>> Kernelnewbies@xxxxxxxxxxxxxxxxx >>>>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>>> >>>> >>>> >>>> -- >>>> ---P.K.S >>>> >>>> _______________________________________________ >>>> Kernelnewbies mailing list >>>> Kernelnewbies@xxxxxxxxxxxxxxxxx >>>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>> >>> >>> >>> -- >>> Ricardo Ribalda >>> >>> _______________________________________________ >>> Kernelnewbies mailing list >>> Kernelnewbies@xxxxxxxxxxxxxxxxx >>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> >> >> >> -- >> "Do or do not. There is no try" >> Yoda Master >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies@xxxxxxxxxxxxxxxxx >> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > -- > Thanks, > Sekhar -- "Do or do not. There is no try" Yoda Master _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
