18 Mar
2003
18 Mar
'03
1:21 p.m.
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