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 [EMAIL PROTECTED]
Please read the FAQ at http://kernelnewbies.org/FAQ
