Hi, Thomas,
have you seen this version?
Thanks,
Kirill
30.05.2014, 00:52, "Kirill Tkhai" :
> В Ср, 28/05/2014 в 22:26 +0200, Thomas Gleixner пишет:
>> On Mon, 5 May 2014, Kirill Tkhai wrote:
>>> В Сб, 03/05/2014 в 20:54 +0200, Thomas Gleixner пишет:
Though exercising that code path as mu
В Ср, 28/05/2014 в 22:26 +0200, Thomas Gleixner пишет:
> On Mon, 5 May 2014, Kirill Tkhai wrote:
> > В Сб, 03/05/2014 в 20:54 +0200, Thomas Gleixner пишет:
> > > Though exercising that code path as much as we can is not a bad thing
> > > either. So I'd like to see that made compile time conditional
On Mon, 5 May 2014, Kirill Tkhai wrote:
> В Сб, 03/05/2014 в 20:54 +0200, Thomas Gleixner пишет:
> > Though exercising that code path as much as we can is not a bad thing
> > either. So I'd like to see that made compile time conditional on one
> > of the lock testing CONFIG items.
>
> +#ifndef CO
В Сб, 03/05/2014 в 20:54 +0200, Thomas Gleixner пишет:
> On Thu, 1 May 2014, Kirill Tkhai wrote:
> > Higher priority does not provide exclusive privilege
> > of one fair task over the other. In this case priority
> > boosting looks excess.
> >
> > On RT patch with enabled PREEMPT_RT_FULL I see a l
On Sun, 4 May 2014, Peter Zijlstra wrote:
> On Sat, May 03, 2014 at 08:54:08PM +0200, Thomas Gleixner wrote:
> > On Thu, 1 May 2014, Kirill Tkhai wrote:
> > > Higher priority does not provide exclusive privilege
> > > of one fair task over the other. In this case priority
> > > boosting looks exces
On Sat, May 03, 2014 at 08:54:08PM +0200, Thomas Gleixner wrote:
> On Thu, 1 May 2014, Kirill Tkhai wrote:
> > Higher priority does not provide exclusive privilege
> > of one fair task over the other. In this case priority
> > boosting looks excess.
> >
> > On RT patch with enabled PREEMPT_RT_FULL
On Thu, 1 May 2014, Kirill Tkhai wrote:
> Higher priority does not provide exclusive privilege
> of one fair task over the other. In this case priority
> boosting looks excess.
>
> On RT patch with enabled PREEMPT_RT_FULL I see a lot of
> rt_mutex_setprio() actions like
>
> 120 -> 118
>
Higher priority does not provide exclusive privilege
of one fair task over the other. In this case priority
boosting looks excess.
On RT patch with enabled PREEMPT_RT_FULL I see a lot of
rt_mutex_setprio() actions like
120 -> 118
118 -> 120
They harm RT tasks.
RT patch has lazy
8 matches
Mail list logo