Mulyadi Santosa wrote: > Sorry for getting back late.. No problem. I am enjoying our conversation, so reply whenever you are free. >> Process A is the highest priority >> Process B is lowest realtime priority (which is higher prio than >> non-realtime keventd) Process A reads from the device driver >> Process B runs because A is blocked >> Interrupt fires, schedules workqueue to read data on behalf of >> process A Process B runs, because it is a higher priority than >> keventd <- Priority inversion here >> >> Process B is running, but A should be running, so this is priority >> inversion. >> > OK I understand your offered scenario. However, AFAIK, since B was > assigned realtime prio, it will chew all the available CPU > time, unless > it voluntarily gives up the processor. In other word, it's not just > priority inversion, but bad starvation. I have to disagree with you about bad starvation. Priority inversion can not exist without CPU contention. If you don't consider this scenario priority inversion, how would you define priority inversion? >> (*) I am defining "want" for a tasklet to mean that it "wants" to >> run as soon as possible after the current or next hardware >> interrupt, not immediately. > > OK, I got this part. Sometimes we need a bit lengthy discussion to > understand each other's thinking :) Agreed. For what its worth, I would still call the tasklet scenario priority inversion. To expand the situation: Process A is the highest priority Process B is lowest realtime priority Process A reads from the device driver Process B runs because A is blocked Interrupt fires, schedules tasklet to read data on behalf of process Process B runs again because no reschedule occurred <- Priority Inversion Timer interrupt fires Ksoftirqd runs tasklet Tasklet wakes up Process A <- Priority Inversion ends Process A runs <- No Priority inversion here The key difference is using tasklets leads to bounded (until the next tick) priority inversion, which should be acceptable for my application. Workqueues lead to unbounded (until B relinquishes the CPU) priority inversion, which is not acceptable in my application. I would love to see a tasklet_rt_schedule in addition to tasklet_schedule and tasklet_hi_schedule. tasklet_rt_schedule would run as soon as possible outside of hardware interrupt context. I am working to better understand the kernel inner-workings, and I hope that I could propose such a patch someday. Unfortunately, I still have a lot of learning to do before then. That being said, conversations like this form a big part of said learning. Thanks again, Michael -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
