From 50677bf806e73d6b2bf940e0192f170b7bbaf3e4 Mon Sep 17 00:00:00 2001 From: Andreas Kling Date: Mon, 30 Dec 2019 18:46:17 +0100 Subject: Kernel: Refactor scheduler to use dynamic thread priorities Threads now have numeric priorities with a base priority in the 1-99 range. Whenever a runnable thread is *not* scheduled, its effective priority is incremented by 1. This is tracked in Thread::m_extra_priority. The effective priority of a thread is m_priority + m_extra_priority. When a runnable thread *is* scheduled, its m_extra_priority is reset to zero and the effective priority returns to base. This means that lower-priority threads will always eventually get scheduled to run, once its effective priority becomes high enough to exceed the base priority of threads "above" it. The previous values for ThreadPriority (Low, Normal and High) are now replaced as follows: Low -> 10 Normal -> 30 High -> 50 In other words, it will take 20 ticks for a "Low" priority thread to get to "Normal" effective priority, and another 20 to reach "High". This is not perfect, and I've used some quite naive data structures, but I think the mechanism will allow us to build various new and interesting optimizations, and we can figure out better data structures later on. :^) --- Kernel/Syscall.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Kernel/Syscall.h') diff --git a/Kernel/Syscall.h b/Kernel/Syscall.h index 3487f264d5..3b5df184c4 100644 --- a/Kernel/Syscall.h +++ b/Kernel/Syscall.h @@ -270,7 +270,7 @@ struct SC_futex_params { struct SC_create_thread_params { unsigned int m_detach_state = 0; // JOINABLE or DETACHED - int m_schedule_priority = 2; // ThreadPriority::Normal + int m_schedule_priority = 30; // THREAD_PRIORITY_NORMAL // FIXME: Implment guard pages in create_thread (unreadable pages at "overflow" end of stack) // "If an implementation rounds up the value of guardsize to a multiple of {PAGESIZE}, // a call to pthread_attr_getguardsize() specifying attr shall store in the guardsize -- cgit v1.2.3