> From: Robert Love [mailto:[email protected]]
> On Wed, 2003-06-18 at 23:52, Perez-Gonzalez, Inaky wrote:
>
> > Then some output would show on my serial console when events/0 is
> > reprioritized...
> >
> > OTOH, what do you think of Robert's idea of adding 20 levels of
> > priorities for the kernel's sole use?
>
> That was your idea, I just said the infrastructure was in place and we
> could do it ;-)
I stand corrected (Man! I should really have my fingers typing
after my brain thinks it).
> I am not so sure it is ideal. I hesitate to make kernel threads FIFO at
> a maximum priority, let alone an even greater one. I would really prefer
> to find a nicer solution. Anyhow, if we make events FIFO/99 that would
> also solve the problem, without dipping into extra high levels.
I don't think is ideal either, but it is the only way I see where we
can make sure that no user thread is going to stomp over the kernel
toes and cause a deadlock (this is a extreme, but it can happen). If
by default we ship all the kernel threads at higher priority than
anything that the user can do, we avoid this problem (of course, some
are going to be a no-no, so we default them to OTHER -20), but the
most common ones to cause trouble, like the migration thread, keventd
and some else might benefit from this.
Then, being then the user/sysadmin/designer able to tweak them
up or down at will could fix many potential issues with this.
(eg: customer who has decided his applications are real-time,
and thus have to be made SCHED_FIFO/50 and without any warning or
possible cause, they are deadlocking while on some other systems
they work flawlessly ... )
I?aky P?rez-Gonz?lez -- Not speaking for Intel -- all opinions are my own
(and my fault)
On Thu, 2003-06-19 at 11:31, Perez-Gonzalez, Inaky wrote:
> I don't think is ideal either, but it is the only way I see where we
> can make sure that no user thread is going to stomp over the kernel
> toes and cause a deadlock (this is a extreme, but it can happen).
Hmm, I guess a deadlock _is_ possible but I think the issue is more of
starvation.
And we can prevent starvation just by running the kernel thread at
FIFO/99, because then it will never be starved by a higher priority
task. If the RT task being starved is also at priority 99, it will
eventually block (as in our example, on console I/O) and let the kernel
thread run. If the RT task being starved is lower priority, then there
is nothing to worry about.
I guess a real deadlock could only occur if the FIFO/99 task does not
block on the resource the kernel thread is providing but busy loops
waiting for it.
It is all a trade off, and rarely a pleasant one...
Robert Love