doubt on schedule_work() - work task getting scheduled lately

[Daniel.]

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 at gmail.com>:
> On Fri, Jul 29, 2016 at 9:05 PM, Daniel. <danielhilst at gmail.com> wrote:
>> Nice tool @Ricardo!
>>
>> 2016-07-29 10:48 GMT-03:00 Ricardo Ribalda Delgado <ricardo.ribalda at gmail.com>:
>>> 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 at gmail.com> wrote:
>>>> On Fri, Jul 29, 2016 at 4:02 PM, Muni Sekhar <munisekharrms at gmail.com> 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 at kernelnewbies.org
>>>>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>>
>>>>
>>>>
>>>> --
>>>>         ---P.K.S
>>>>
>>>> _______________________________________________
>>>> Kernelnewbies mailing list
>>>> Kernelnewbies at kernelnewbies.org
>>>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>
>>>
>>>
>>> --
>>> Ricardo Ribalda
>>>
>>> _______________________________________________
>>> Kernelnewbies mailing list
>>> Kernelnewbies at kernelnewbies.org
>>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>>
>> --
>> "Do or do not. There is no try"
>>   Yoda Master
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
>
> --
> Thanks,
> Sekhar



-- 
"Do or do not. There is no try"
  Yoda Master