Subject: Re: [linux-audio-dev] new realtime scheduling policy
From: Roger Larsson (roger.larsson_AT_skelleftea.mail.telia.com)
Date: Tue Mar 18 2003 - 19:07:24 EET
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
This archive was generated by hypermail 2b28 : Tue Mar 18 2003 - 19:15:45 EET