sched: Use a relative alarm
authorBarret Rhoden <brho@cs.berkeley.edu>
Mon, 14 Aug 2017 13:42:52 +0000 (09:42 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Mon, 14 Aug 2017 21:02:20 +0000 (17:02 -0400)
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>
kern/src/schedule.c

index 2490c52..70102a1 100644 (file)
@@ -92,10 +92,12 @@ static void __ksched_tick(struct alarm_waiter *waiter)
 {
        /* 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);
 }