[linux-audio-dev] new realtime scheduling policy

[Roger Larsson]

On Tuesday 18 March 2003 08:45, rm wrote:
> hi all, 
> 
>      so i've tried to make a new scheduling policy for linux.  i've
> called it SCHED_USERFIFO.  the intent is basically to allow a process
> ask for x amount of processor time out of every y jiffies.  (the user
> part is in the hope that the administrator can set rlimits on the
> amount of percentage of time requested and allow non-priviledged users
> to use this policy without being able to complete hang the box).

With 2.4 kernels there are very few jiffies to share, 2.5 kernels have more.
But jiffies are not a good unit...

The second problem is that this patch adds code to hot areas in the kernel -
it will slow down context switching for all processes.
This can be made slightly better if you add unlikely/likely from
linux/compiler.h

> - - -
> here is the kernel patch.
> 
> --- pristine/linux-2.4.20/kernel/sched.c	2003-03-17 23:24:02.000000000 -0500
> +++ linux/kernel/sched.c	2003-03-17 22:11:13.000000000 -0500
> @@ -188,7 +188,42 @@
>  	 * runqueue (taking priorities within processes
>  	 * into account).
>  	 */
> +
> +	if (p->policy == SCHED_USERFIFO) { 
> +	  
> +	  /*
> +	   *   check if we are in the right time period
> +	   *
> +	   *   XXX if it burns though it's entire period and
> +	   *       into the next ? 
> +	   *     
> +	   */
> +	  if (jiffies >= p->t_period_end) { 

this wont work when jiffies wrap... I think there are functions/macros
that can check this - time_after_eq?
linux/include/linux/timer.h

> @@ -964,6 +999,15 @@
>  	retval = 0;
>  	p->policy = policy;
>  	p->rt_priority = lp.sched_priority;
> +	
> +	if (policy == SCHED_USERFIFO) { 
> +	  /* FIXME: no checks, doesn't handle jiffy rollover */
> +	  p->t_period_length = lp.period_length; 
> +	  p->t_period_reserved = lp.period_reserved;
> +	  p->t_period_start = jiffies;
> +	  p->t_period_end = p->t_period_length + p->t_period_start;
> +	  p->t_period_remain = p->t_period_reserved; 

jiffies frequency depends on architecture and compilation options.
At least you should scale with HZ in some way for wall clock parameters.
(micro/nano seconds?)

> --- pristine/linux-2.4.20/include/linux/sched.h	2003-03-17 
> @@ -419,6 +422,15 @@
>  
>  /* journalling filesystem info */
>  	void *journal_info;
> +
> +
> +  /* our extra stuff */ 
> +
> +  unsigned long t_period_end; 
> +  unsigned long t_period_start; 
> +  unsigned long t_period_remain;
> +  unsigned long t_period_length;
> +  unsigned long t_period_reserved;

This will not be liked - growing task_struct with 4*5=20 bytes for every 
task... (This is probably the most important issue)

Could this data be made CPU local?
Assume that SCHED_USERFIFO were handled in a strict FIFO manner, no 
priorities, then a running process of that class can only be suspended by a
SCHED_FIFO or SCHED_RR



Anyway, I think this patch has its place on linux-kernel. It will most likely 
be rejected but it shows that people are interested in these issues...
(Who knows Ingo might get another bright idea... :-)

/RogerL


-- 
Roger Larsson
Skellefteå
Sweden