Hi...
Sorry for getting back late..
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.
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 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.
Hmm... yes I fairly agree.
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
Again, you missed the assumption that B is a realtime
process...thus...it will run again after being interrupted.
(*) 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 :)
regards,
Mulyadi
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
