Re: rt20 patch question

[Mark Hounschell]

Steven Rostedt wrote:
> (It is expected on LKML to not touch the CC list, and especially keep the
> one you are replying to)
> 
Ok. I'm on so many it's hard to remember what each want.

> On Tue, 9 May 2006, Mark Hounschell wrote:
> 
>> Daniel Walker wrote:
>>> On Tue, 2006-05-09 at 08:23 -0400, Mark Hounschell wrote:
>>>> Can I assume configuring 'Complete preemption' is the same as
>>>> configuring ('Voluntary preemption' + 'Hardirq' + 'Softirq' + default
>>>> proc settings)?
>>> Not Voluntary preemption, and I'm not sure what default proc settings is
>>> referring too .
>> The proc settings or boot options to enable or disable hardirq or
>> softirq threading that you have avaialable in Voluntary preemption.
>>
>>> Complete preemption is like CONFIG_PREEMPT and softirq
>>> and hardirq threading .. The preemption isn't voluntary, it's forced .
>>>
>> Complete preemption you have no choice of threading hard or soft irqs.
>> They are threaded.
>>
>> So If I config Voluntary preemption + Hardirq and Softirq threading and
>> do not disable hardirq or softirq via proc or boot cmdline, is that the
>> same as configuring Complete preemption?
>>
> 
> No not at all.
> 
> First Voluntary preemption means that when you are executing in the
> kernel, and a higher priority process needs to run, the kernel will _not_
> be preempted!  Voluntary preemption means that there are places in the
> kernel that are marked as preemption points.  So if you are in the kernel
> and you hit a preemption point, a check is made then to see if the
> scheduler should be called. So, really this is not a true preemptive
> kernel.
> 
> Next you have "Preemptible Kernel (Low Latency Desktop)".  This _is_ a
> preemptive kernel.  Which means that, unless preemption is disabled, the
> default is to preempt a process whether or not it's in the kernel if
> either it finished it's run time, or a higher priority process wants to
> run.  There is protective places in the kernel that disallow preemption
> (basically between spinlocks and preempt_enable/disable).
> 
> But even with Preemptible Kernel + Hardirq and Softirq threading, you
> still don't have the same as complete preemption.  This is because the
> full preemption turns the spinlocks into mutexes that are not only
> preemptible, but schedule on contention.  To do this, Hard and Soft irqs
> must be threaded.  This is because they use spinlocks, and to schedule
> in an interrupt, it must be acting as a thread.  So you can't have full
> complete preemption without threading the Hard and Soft irqs, and that's
> why there is no option to not have them threaded.
> 
> Without full preemption, you also lose out on having the PI for the
> spinlock mutexes.
> 
> -- Steve
> 
> 

Thank you. That is exactly what I wanted to know. I ask because when I
run my app in complete preemption mode I have random periods where the
machine stops for many seconds at a time. Only in complete preemption
mode does this happen. In Voluntary and Preempt modes this does not
occure. I'm having a hard time trying to determine if the problem is in
my application.

Mark
-
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/