Mulyadi Santosa wrote: >> Thank you Mulyadi! Is there a recommended way to prevent priority >> inversion when high priority tasks are waiting on data from a driver? > > Well, IMHO that's not called priority inversion, but just a matter of > reducing blocking situation. And as long as you sleep while blocking, > not busy looping, I say it's just fine. You can't really avoid that > situation in many cases... This situation does not exhibit priority inversion, but it could if you add another process: 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. > >> Do I just need to do all processing either in the syscall context or >> under interrupt priority? > > Whenever possible, do lengthy operation on process context. I agree lengthy operations should be done in process context. By processing here I just meant whatever is necessary to communicate with hardware and do minimal internal book-keeping. > >> Just be be sure: timers and tasklets run under a software interrupt >> context > true... >> therefore have a higher priority than all user processs > > Not really. I don't think they have "priority". The reality I see is, > they are executed whenever the kernel code path back from interrupt to > kernel/user space.. or at least when ksoftirqd gets a chance to run. > Perhaps that's what you mean by "seems having higher priority than > all user process". Exactly. I didn't mean that these have a priority field and are schedule-able, just that if a user proccess "wants" to run at the same time a tasklet/timer "wants" to run, the tasklet/timer will run*. Using my above example: 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 tasklet to read data on behalf of process A Ksoftirqd runs tasklet Tasklet wakes up Process A Process A runs <- No Priority inversion here Thank you again, Michael (*) 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. -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
