Nick's scheduler policy v8
Subsystems (3)
PATCH 1/1 Nick's scheduler policy v8
Hi,
No big changes, this one takes some of the steepness out of the timeslice curve and fixes a bug with child priorities which might or might not help startup times. Probably no point doing any benchmarks on it if they've been done on v7.
It seems to be better than v7 here without X being reniced, however renicing X to say -10 always seems to help.
Against 0-test4
include/linux/sched.h renamed from linux-2.6/include/linux/sched.h +9 -2
@@ -281,7 +281,9 @@ struct signal_struct {#define MAX_RT_PRIO MAX_USER_RT_PRIO#define MAX_PRIO (MAX_RT_PRIO + 40) - + +#define rt_task (p) ((p)->prio < MAX_RT_PRIO) +/* * Some day this will be a full-fledged user tracking system.. */
@@ -339,12 +341,16 @@ struct task_struct {struct list_head run_list;prio_array_t *array; +unsigned long array_sequence; +unsigned long timestamp; + +unsigned long total_time, sleep_time;unsigned long sleep_avg; -unsigned long last_run;unsigned long policy;cpumask_t cpus_allowed;unsigned int time_slice, first_time_slice; +unsigned int used_slice;struct list_head tasks;struct list_head ptrace_children;
@@ -552,6 +558,7 @@ extern int FASTCALL(wake_up_state(structextern int FASTCALL (wake_up_process (struct task_struct * tsk));extern int FASTCALL (wake_up_process_kick (struct task_struct * tsk));extern void FASTCALL (wake_up_forked_process (struct task_struct * tsk)); +extern void FASTCALL (sched_fork (task_t * p));extern void FASTCALL (sched_exit (task_t * p));asmlinkage long sys_wait4 (pid_t pid,unsigned int * stat_addr,int options,struct rusage * ru);
kernel/fork.c renamed from linux-2.6/kernel/fork.c +3 -27
@@ -911,33 +911,9 @@ struct task_struct *copy_process(unsigne p->exit_signal = (clone_flags &CLONE_THREAD ) ?-1 : (clone_flags &CSIGNAL ); p->pdeath_signal =0 ; -/* -* Share the timeslice between parent and child, thus the -* total amount of pending timeslices in the system doesn't change, -* resulting in more scheduling fairness. -*/ -local_irq_disable (); - p->time_slice = (current->time_slice +1 ) >>1 ; -/* -* The remainder of the first timeslice might be recovered by -* the parent if the child exits early enough. -*/ - p->first_time_slice =1 ; - current->time_slice >>=1 ; - p->last_run = jiffies; -if (!current->time_slice) { -/* -* This case is rare, it happens when the parent has only -* a single jiffy left from its timeslice. Taking the -* runqueue lock is not a problem. -*/ - current->time_slice =1 ; -preempt_disable (); -scheduler_tick (0 ,0 ); -local_irq_enable (); -preempt_enable (); - }else -local_irq_enable (); +/* Perform scheduler related accounting */ +sched_fork (p); +/* * Ok, add it to the run-queues and make it * visible to the rest of the system.
kernel/sched.c renamed from linux-2.6/kernel/sched.c +242 -209
662 lines not on this page · raw message
Quoted 4 lines · Nick Piggin
No big changes, this one takes some of the steepness out of the timeslice curve and fixes a bug with child priorities which might or might not help startup times. Probably no point doing any benchmarks on it if they've been done on v7.
I've been playing with it for a while and, from what I've seen until date, I must say it makes X feel smooth (even when X not reniced, although I've reniced it to -20). However, it still feels a little bit slower when forking new processes under heavy load. I'll do some benchmarking and will post numbers here.
Thanks!
Quoted 9 lines · Felipe Alfaro Solana
Quoted 5 lines · Nick Piggin
No big changes, this one takes some of the steepness out of the timeslice curve and fixes a bug with child priorities which might or might not help startup times. Probably no point doing any benchmarks on it if they've been done on v7.
Quoted 7 lines
I've been playing with it for a while and, from what I've seen until date, I must say it makes X feel smooth (even when X not reniced, although I've reniced it to -20). However, it still feels a little bit slower when forking new processes under heavy load. I'll do some benchmarking and will post numbers here.
Thanks!
Hi Felipe,
Sorry I can't reply directly to you. Something thinks I'm spam... Anyway, thanks for all your good feedback. The slower fork response is something I haven't been able to get quite right without causing kernel compiles to slow things down _too_ much. I have a few more ideas though.