From mboxrd@z Thu Jan 1 00:00:00 1970 From: mulyadi.santosa@gmail.com (Mulyadi Santosa) Date: Fri, 5 Aug 2016 12:44:07 +0700 Subject: doubt on schedule_work() - work task getting scheduled lately In-Reply-To: References: Message-ID: To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org On Fri, Jul 29, 2016 at 5:32 PM, Muni Sekhar 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__); > > 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); > > return IRQ_HANDLED; > } > > -- > Thanks, > Sekhar > > Hi Sekhar In general, in non real time kernel, there is no way you can make sure your work will be scheduled after N seconds. Have you done simple statistic calculation how much % it is slower than 100 us, and how much % it is faster than 100 us? IMHO, if slower % is lower than 1% of overall sample, I think it is still acceptable, but this is up to your judgement BTW, like other said too, that mutex_lock, have you also measured how long, by average, the lock is taken? -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160805/5649a508/attachment-0001.html