sched: Use a relative alarm Some syscalls, notably writing to the serial console, take a very long time. If you cat a large file to the console, your other SCPs (notably SSH and shells) get nearly no service. The ksched backlogs about a dozen ksched_ticks during the syscalls, which are O(100ms). With this change, those other processes get a little more attention. Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>

diff --git a/kern/src/schedule.c b/kern/src/schedule.c
index 2490c52..70102a1 100644
--- a/kern/src/schedule.c
+++ b/kern/src/schedule.c

@@ -92,10 +92,12 @@
 {
 	/* TODO: imagine doing some accounting here */
 	run_scheduler();
-	/* Set our alarm to go off, incrementing from our last tick (instead of
-	 * setting it relative to now, since some time has passed since the alarm
-	 * first went off.  Note, this may be now or in the past! */
-	set_awaiter_inc(&ksched_waiter, TIMER_TICK_USEC);
+	/* Set our alarm to go off, relative to now.  This means we might lag a bit,
+	 * and our ticks won't match wall clock time.  But if we do incremental,
+	 * we'll actually punish the next process because the kernel took too long
+	 * for the previous process.  Ultimately, if we really care, we should
+	 * account for the actual time used. */
+	set_awaiter_rel(&ksched_waiter, TIMER_TICK_USEC);
 	set_alarm(&per_cpu_info[core_id()].tchain, &ksched_waiter);
 }