Re: [PATCH] [request for inclusion] Realtime LSM

["Jack O'Quin" <joq@io.com>]

Ingo Molnar <mingo@elte.hu> writes:

> the RT-LSM thing is a bit dangerous because it doesnt really protect
> against a runaway, buggy app. So i think the right way to approach this
> problem is to not apply RT-LSM for the time being, but to provide an
> 'advanced latency needs' scheduling class that is _still_ safe even if
> the task is runaway, but behaves with near-RT priorities if the task is
> 'nice' (i.e. doesnt use up large amount of CPU time.)

You are right that a runaway SCHED_FIFO application can freeze the
system.  But, this really has nothing to do with the permissions
problem addressed by the realtime-lsm.  In fact, it is needed by
non-root users for running `nice -20', just as for SCHED_FIFO.

I have no objection to creating a "better" RT scheduling class than
SCHED_FIFO.  The "much-maligned" Mac OS X has a deadline scheduler
that works quite well for running JACK and its applications.

> so, could you try vanilla 2.6.10 (without LSM and without jackd running
> with RT priorities), with jackd set to nice -20? Make sure the
> jack-client process gets this priority too. Best to achieve this is to
> renice a shell to -20 and start up everything from there - the nice
> settings will be inherited. How does such an audio test compare to a
> test done with jackd running at SCHED_FIFO with RT priority 1?

For a quick comparison, I used a slightly modified version of the
jack_test3.2 script, that runs jackd without the -R (--realtime)
option...

                                 With -R        Without -R
                               (SCHED_FIFO)     (nice -20)

************* SUMMARY RESULT ****************
Total seconds ran . . . . . . :   300
Number of clients . . . . . . :    20
Ports per client  . . . . . . :     4
Frames per buffer . . . . . . :    64
*********************************************
Timeout Count . . . . . . . . :(    1)          (    1)         
XRUN Count  . . . . . . . . . :     2             2837          
Delay Count (>spare time) . . :     0                0          
Delay Count (>1000 usecs) . . :     0                0          
Delay Maximum . . . . . . . . :  3130   usecs    5038044   usecs
Cycle Maximum . . . . . . . . :   960   usecs    18802   usecs
Average DSP Load. . . . . . . :    34.3 %           44.1 %    
Average CPU System Load . . . :     8.7 %            7.5 %    
Average CPU User Load . . . . :    29.8 %            5.2 %    
Average CPU Nice Load . . . . :     0.0 %           20.3 %    
Average CPU I/O Wait Load . . :     3.2 %            5.2 %    
Average CPU IRQ Load  . . . . :     0.7 %            0.7 %    
Average CPU Soft-IRQ Load . . :     0.0 %            0.2 %    
Average Interrupt Rate  . . . :  1707.6 /sec      1677.3 /sec 
Average Context-Switch Rate . : 11914.9 /sec     11197.6 /sec 
*********************************************

This was not exactly the test you requested.  The LSM is still
present.  But, it makes no difference.  In fact, I used it to grant
nice privileges, since I didn't feel like running it as root.

But this is otherwise vanilla 2.6.10, and the two scheduling
algorithms are fairly represented.  Try it yourself, I think you'll
see similarly dramatic differences.

Note that 2.6.10 has by far the best realtime performance of any
vanilla Linux kernel I have ever tried.  Although, much better results
can be obtained with your Realtime Preemption patches, this is still a
very creditable result, quite usable for many relatively low-latency
applications.  Kudos to you and the many others who contributed to
this achievement.

> if this works out well then we could achieve something comparable to
> RT-LSM, via nice levels alone.

As you see, it does not work at all.
-- 
  joq