Re: [RFC PATCH v2] Softirq:avoid large sched delay from the pending softirqs

On Thu, Jul 23, 2020 at 2:05 AM Thomas Gleixner wrote: > > qianjun.ker...@gmail.com writes: > > + > > + end = ktime_get(); > > + delta = ktime_to_us(end - start); > > What's the point of this conversion? That's a division for no value > because you can simply define the

Re: [RFC PATCH v2] Softirq:avoid large sched delay from the pending softirqs

qianjun.ker...@gmail.com writes: > + > + end = ktime_get(); > + delta = ktime_to_us(end - start); What's the point of this conversion? That's a division for no value because you can simply define the maximum time in nanoseconds with the same effect, i.e. ktime_t

Re: [RFC PATCH v2] Softirq:avoid large sched delay from the pending softirqs

Hi Peter & Uladzislau Are there any issues that have not been considered in this patch? Can you give me some suggestions on this issue. If the situation I described is indeed a problem，how about this modification. Thanks a lot. On Mon, Jul 20, 2020 at 9:09 PM wrote: > > From: jun qian > > When

[RFC PATCH v2] Softirq:avoid large sched delay from the pending softirqs

From: jun qian When get the pending softirqs, it need to process all the pending softirqs in the while loop. If the processing time of each pending softirq is need more than 2 msec in this loop, or one of the softirq will running a long time, according to the original code logic, it will process