Hi Ming, On 05/09/2019 11:06, Ming Lei wrote: > On Wed, Sep 04, 2019 at 07:31:48PM +0200, Daniel Lezcano wrote: >> Hi, >> >> On 04/09/2019 19:07, Bart Van Assche wrote: >>> On 9/3/19 12:50 AM, Daniel Lezcano wrote: >>>> On 03/09/2019 09:28, Ming Lei wrote: >>>>> On Tue, Sep 03, 2019 at 08:40:35AM +0200, Daniel Lezcano wrote: >>>>>> It is a scheduler problem then ? >>>>> >>>>> Scheduler can do nothing if the CPU is taken completely by handling >>>>> interrupt & softirq, so seems not a scheduler problem, IMO. >>>> >>>> Why? If there is a irq pressure on one CPU reducing its capacity, the >>>> scheduler will balance the tasks on another CPU, no? >>> >>> Only if CONFIG_IRQ_TIME_ACCOUNTING has been enabled. However, I don't >>> know any Linux distro that enables that option. That's probably because >>> that option introduces two rdtsc() calls in each interrupt. Given the >>> overhead introduced by this option, I don't think this is the solution >>> Ming is looking for. >> >> Was this overhead reported somewhere ? > > The syscall of gettimeofday() calls ktime_get_real_ts64() which finally > calls tk_clock_read() which calls rdtsc too. > > But gettimeofday() is often used in fast path, and block IO_STAT needs to > read it too. > >> >>> See also irqtime_account_irq() in kernel/sched/cputime.c. >> >> From my POV, this framework could be interesting to detect this situation. > > Now we are talking about IRQ_TIME_ACCOUNTING instead of IRQ_TIMINGS, and the > former one could be used to implement the detection. And the only sharing > should be the read of timestamp. You did not share yet the analysis of the problem (the kernel warnings give the symptoms) and gave the reasoning for the solution. It is hard to understand what you are looking for exactly and how to connect the dots. AFAIU, there are fast medium where the responses to requests are faster than the time to process them, right? I don't see how detecting IRQ flooding and use a threaded irq is the solution, can you explain? If the responses are coming at a very high rate, whatever the solution (interrupts, threaded interrupts, polling), we are still in the same situation. My suggestion was initially to see if the interrupt load will be taken into accounts in the cpu load and favorize task migration with the scheduler load balance to a less loaded CPU, thus the CPU processing interrupts will end up doing only that while other CPUs will handle the "threaded" side. Beside that, I'm wondering if the block scheduler should be somehow involved in that [1] -- Daniel [1] https://www.linaro.org/blog/io-bandwidth-management-for-production-quality-services/ -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog
