On 2022-06-09 15:46:04 [+0000], David Laight wrote: > From: Sebastian Andrzej Siewior > > Sent: 09 June 2022 16:03 > > > > On 2022-05-30 16:15:11 [-0700], Davidlohr Bueso wrote: > > > Tasklets have long been deprecated as being too heavy on the system > > > by running in irq context - and this is not a performance critical > > > path. If a higher priority process wants to run, it must wait for > > > the tasklet to finish before doing so. > > > > > > Process srps asynchronously in process context in a dedicated > > > single threaded workqueue. > > > > I would suggest threaded interrupts instead. The pattern here is the > > same as in the previous driver except here is less locking. > > How long do these actions runs for, and what is waiting for > them to finish? That is something that one with hardware and workload can answer. > These changes seem to drop the priority from above that of the > highest priority RT process down to that of a default priority > user process. > There is no real guarantee that the latter will run 'any time soon'. Not sure I can follow. Using threaded interrupts will run at FIFO-50 by default. Workqueue however is SCHED_OTHER. But then it is not bound to any CPU so it will run on an available CPU. > Consider some workloads I'm setting up where most of the cpu are > likely to spend 90%+ of the time running processes under the RT > scheduler that are processing audio. > > It is quite likely that a non-RT thread (especially one bound > to a specific cpu) won't run for several milliseconds. > (We have to go through 'hoops' to avoid dropping ethernet frames.) > > I'd have thought that some of these kernel threads really > need to run at a 'middling' RT priority. The threaded interrupts do this by default. If you run your own RT threads you need to decide if they are more or less important than the interrupts. > David Sebastian
