Re: [PATCH] sched - Implement priority and fifo support for SCHED_ISO

[Con Kolivas <kernel@kolivas.org>]

[-- Attachment #1: Type: text/plain, Size: 2149 bytes --]

Jack O'Quin wrote:
> Con Kolivas <kernel@kolivas.org> writes:
> 
> 
>>While it is not clear what form the final soft real time
>>implementation is, we should complete the partial implementation of
>>SCHED_ISO that is in 2.6.11-rc2-mm1.
> 
> 
> I finally had a chance to try this today.  I applied a slightly
> different patch (2.6.11-rc2-iso3.diff) on top of patch-2.6.11-rc2.  I
> tried to use 2.6.11-rc2-mm2, but could not due to conflicts with other
> scheduler updates.
> 
> It is not clear whether the realtime threads are running in the new
> scheduler class.  Checking with schedtool yields odd results.
> (Before, my old schedtool always said "POLICY I: SCHED_ISO".)
> 
> [joq@sulphur] jack_test/ $ pst jackd
>  2173  2173 TS       -   0  19   0  0.0 SLs  rt_sigsuspend  jackd
>  2174  2174 ?       21   0  60   0  0.0 SL   -              jackd
>  2175  2175 TS       -   0  23   0  0.0 SL   rt_sigsuspend  jackd
>  2176  2176 TS       -   0  23   0  0.0 SL   -              jackd
>  2177  2177 ?       20   0  59   0  0.0 SL   syscall_call   jackd
>  2178  2178 ?       10   0  49   0  1.7 SL   -              jackd
> [joq@sulphur] jack_test/ $ schedtool 2174 2176 2177 2178
> PID  2174: PRIO  21, POLICY (null)         , NICE  0
> PID  2176: PRIO   0, POLICY N: SCHED_NORMAL, NICE  0
> PID  2177: PRIO  20, POLICY (null)         , NICE  0
> PID  2178: PRIO  10, POLICY (null)         , NICE  0

They're SCHED_ISO_FIFO which schedtool doesn't know about.

> The results of the first run indicate something is badly wrong.  It is
> quite possible that I got confused and messed up the build somehow.
> 
>   http://www.joq.us/jack/benchmarks/sched-iso3/jack_test3-2.6.11-rc2-q1-200501311225.log
>   http://www.joq.us/jack/benchmarks/sched-iso3/jack_test3-2.6.11-rc2-q1-200501311225.png
> 
> Loading the realtime-lsm and then running with SCHED_FIFO *does* work
> as expected on this kernel.  I should retry the test with *exactly*
> the expected patch sequence.  What would that be?

Shouldn't matter. There must still be something wrong with my code... 
sigh. I'll look into it at some stage, but there doesn't seem much point.

Cheers,
Con

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]