2018-01-09 14:36 UTC+01:00, Dmitry Safonov <d...@arista.com>: > Warning: Not merge-ready > > I. Current workflow of ksoftirqd. > Softirqs are processed in the context of ksoftirqd iff they are > being raised very frequently. How it works: > do_softirq() and invoke_softirq() deffer pending softirq iff > ksoftirqd is in runqueue. Ksoftirqd is scheduled mostly in the > end of processed softirqs if 2ms were not enough to process all > pending softirqs. > > Here is pseudo-picture of the workflow (for simplicity on UMP): > ------------- ------------------ ------------------ > | ksoftirqd | | User's process | | Softirqs | > ------------- ------------------ ------------------ > Not scheduled Running > | > o------------------------o > | > __do_softirq() > | > 2ms & softirq pending? > Schedule ksoftirqd > | > Scheduled o------------------------o > | > o--------------------o > | > Running Scheduled > | > o--------------------o > | > Not scheduled Running > > Timegraph for the workflow, > dash (-) means ksoftirqd not scheduled; > equal(=) ksoftirqd is scheduled, a softirq may still be pending > > Pending softirqs > | | | | | | | | | > v v v v | | | | v > Processing o-----o | | | | o--o > softirqs | | | | | | | | > | | | | | | | | > | | | | | | | | > Userspace o-o o=========o | | | | o----o o---------o > <-2ms-> | | | | | | > | v v v v | > Ksoftirqd o----------o > > II. Corner-conditions. > During testing of commit [1] on some non-mainstream driver, > I've found that due to platform specifics, the IRQ is being > raised too late (after softirq has been processed).
I'm a bit confused about that part. I would expect the softirq to be raised by the IRQ. So I guess in this scenario the softirq is raised by something else and you expect the upcoming IRQ to handle the softirq, right? (sorry I'm not used to networking code). Thanks. > In result softirqs steal time from userspace process, leaving > it starving for CPU time and never/rarely scheduling ksoftirqd:
