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

["Jack O'Quin" <joq@xxxxxx>]

Ingo Molnar <mingo@xxxxxxx> writes:

> what kind of non-audio workload was there during this test? 43 xruns
> arent nice but arent that bad either.

Audio playback through JACK didn't work well at all with nice --20,
even at relatively high latencies (23 msec cycle).  It was bad enough
that I would not want to use it for anything.  

The 1/2 second max delay was probably more of an issue than the number
of xruns.  Something really bad happened there.

> this will turn off starvation checking, for testing purposes. (to see
> whether there's anything else but anti-starvation causing xruns.)

I build a 2.6.10 kernel with just these two changes...

--- kernel/sched.c~	Fri Dec 24 15:35:24 2004
+++ kernel/sched.c	Wed Jan 12 23:48:49 2005
@@ -95,7 +95,7 @@
 #define MAX_BONUS		(MAX_USER_PRIO * PRIO_BONUS_RATIO / 100)
 #define INTERACTIVE_DELTA	  2
 #define MAX_SLEEP_AVG		(DEF_TIMESLICE * MAX_BONUS)
-#define STARVATION_LIMIT	(MAX_SLEEP_AVG)
+#define STARVATION_LIMIT	0
 #define NS_MAX_SLEEP_AVG	(JIFFIES_TO_NS(MAX_SLEEP_AVG))
 #define CREDIT_LIMIT		100
 
--- kernel/workqueue.c~	Fri Dec 24 15:35:40 2004
+++ kernel/workqueue.c	Fri Jan 14 19:34:10 2005
@@ -188,7 +188,7 @@
 
 	current->flags |= PF_NOFREEZE;
 
-	set_user_nice(current, -10);
+	set_user_nice(current, -5);
 
 	/* Block and flush all signals */
 	sigfillset(&blocked);

Since realtime-lsm was not available, I ran the test as root.  Overall
system performance was not good.  Trying to do mail with xemacs and
gnus (as I had done before) hung for long periods of time.

The test did not work correctly.  A number of segfaults occurred.  The
jackd server hung and had to be killed manually.

So, these results aren't worth much, but here's what it reported
(compared with earlier results)...


                                 With -R       Without -R      Without -R
                               (SCHED_FIFO)    (nice --20) (STARVATION_LIMIT=0)

************* SUMMARY RESULT ****************
Total seconds ran . . . . . . :   300
Number of clients . . . . . . :    20
Ports per client  . . . . . . :     4
Frames per buffer . . . . . . :    64
*********************************************
Timeout Count . . . . . . . . :(    1)          (    1)       (    2)	      
XRUN Count  . . . . . . . . . :     2               43            46	      
Delay Count (>spare time) . . :     0                0             0	      
Delay Count (>1000 usecs) . . :     0                0             0	      
Delay Maximum . . . . . . . . :  3130 usecs   501374 usecs       0 usecs 
Cycle Maximum . . . . . . . . :   960 usecs     1036 usecs       0 usecs 
Average DSP Load. . . . . . . :    34.3 %         34.3 %        19.5 %     

The "{Delay|Cycle} Maximum" values were apparently not reported
because jackd hung.  I suspect the DSP load went down because many of
the clients crashed.

I ran it again with -R on this kernel, just to check.  The DSP load
was back to 33.2%.  It performed as before, except the "{Delay|Cycle}
Maximum" values were also reported as zero.  Not sure why, don't have
time to debug it right now.  Running with -R did not impact other
interactive processes as badly as nice --20 on this kernel.

If you want, I can dig into this some more and try to figure out what
went wrong.  Did I make the exact changes you wanted?

If it's not interesting, I probably won't bother.
--
 joq
-
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/