The current PI implementation violates POSIX scheduling semantics when
a thread is deboosted. The following patch series adresses this.
Thanks and Kudos go to Mathias Weber and Carsten Emde for analysis,
test cases and initial workaround patches.
Thanks,
tglx
On Wed, 2010-01-20 at 20:58 +0000, Thomas Gleixner wrote:
> The current PI implementation violates POSIX scheduling semantics when
> a thread is deboosted. The following patch series adresses this.
>
> Thanks and Kudos go to Mathias Weber and Carsten Emde for analysis,
> test cases and initial workaround patches.
These look fine to me,
Acked-by: Peter Zijlstra <[email protected]>
On Wed, Jan 20, 2010 at 10:06 PM, Peter Zijlstra <[email protected]> wrote:
> On Wed, 2010-01-20 at 20:58 +0000, Thomas Gleixner wrote:
>> The current PI implementation violates POSIX scheduling semantics when
>> a thread is deboosted. The following patch series adresses this.
>>
>> Thanks and Kudos go to Mathias Weber and Carsten Emde for analysis,
>> test cases and initial workaround patches.
Oh, that sounds good - would you like to share the test cases for our
rt-test suite?
>
> These look fine to me,
>
> Acked-by: Peter Zijlstra <[email protected]>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
On 01/20/2010 09:58 PM, Thomas Gleixner wrote:
> The current PI implementation violates POSIX scheduling semantics when
> a thread is deboosted. The following patch series addresses this.
I can confirm that this patch series fixes the incorrect scheduling
behavior as observed in our test case.
Thanks, Thomas!
Tested-by: Carsten Emde <[email protected]>
On 01/20/2010 09:58 PM, Thomas Gleixner wrote:
>The current PI implementation violates POSIX scheduling semantics when
>a thread is deboosted. The following patch series adresses this.
I did rerun the test case with this patches applied and I can confirm
that this fixes the incorrect scheduling behavior in our test case.
Thanks, Thomas and Carsten for your help.
Tested-by: Mathias Weber <[email protected]>