Re: RT patch acceptance (scheduler) --- QUESTION

[Steven Rostedt]

Darn, I just got a chance to check my email, and I'm coming in very late
to this thread.  Well, I've tried to include everyone that is in on it
so that I can get direct emails too.  I'm very interested in this
thread.

On Wed, 2005-05-25 at 17:12 +0200, Brian O'Mahoney wrote:
> I havnt had time to look at thes patches so could someone
> who has answer the following questions
> 
> - what is the increase in kernel overhead with the full
>   patch enabled

There's a few and I'm sure that others will elaborate further.

wrt. IRQ threads:  Usually when a interrupt goes off, what ever is
running (presumably with interrupts enabled) gets interrupted and the
top level code is executed. With the RT patch, instead each top level
function is implemented by a separate thread.  So instead of just
executing the code at the time of the interrupt, you need to wake up the
corresponding thread instead. Now you have the overhead of a context
switch (two actually, one to get the the thread and another to get back
to what was interrupted). With lots of interrupts going off, you have
lots of context switches.  Not to mention the slight overhead of the
threads themselves.

With the priority inheritance, you have the overhead  of the spin locks
(which are now mutexes) having to do more to check if they are locked.
And if so, they get added to a priority list (if real time).

> 
> - can the patch be configured IN/OUT and if so BUILD/RUN time
> 

The patch is turned on with CONFIG options.  There's also an /proc
interface to change the actions of the kernel at run time if the CONFIGs
were turned on. You can change the way interrupts are preempted, and so
on.

> - I saw the mention of BUG catching, can someone elaborate
> 

I believe that you are talking about the catching problems that are hard
to find in the normal system.  The RT patch allows for much more
preemption and things that are not truly re-entrant but are expected to
be on a SMP system can be found much easier, since you have more context
switches happening at points that are usually protected by a spin lock.
The RT kernel makes the protection of spinlock areas just protected by
those that have the lock, as apposed to just disabling preemption.


Hope this helps,

Gruß,

-- Steve


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/