Hi...
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?
Perhaps you read it incorrectly, I said "not just", not "not" alone :)
In other word, I admitted that it is an example of priority inversion,
which brings impact of very bad starvation.
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.
Although I agree tasklet has a chance to be executed sooner, I don't
really think we could assume it is guaranteed to run at least in the
next tick. In very busy machine such as highlu loaded web servers, there
is a chance tasklets queued by the network interface's driver wait for
several ticks. Perhaps what we need (I am not sure, maybe it's already
implemented?) is "interrupt coalescing" in bottom half i.e 10 interrupt
shots are merged as one, thus CPU is just interrupted once. Of course,
we must provide another data structure that define there are 10 interrupts.
Workqueues lead to unbounded (until B relinquishes the CPU) priority
inversion, which is not acceptable in my application.
There is indeed a crude solution for that :) Manually set keventd as
real time process too :)
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.
i see what you mean. Perhaps, tasklet_rt_schedule isn't created because
kernel developers are afraid it is incorrectly used and leads to
starvation i.e you put lengthy operation inside, thus effectively
leaving other processes waiting for CPU.
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
