mirrors/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-01-23 17:52:26 -05:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Kernel/Scheduler.cpp

674 lines
23 KiB
C++
Raw Normal View History

Meta: Add license header to source files As suggested by Joshua, this commit adds the 2-clause BSD license as a comment block to the top of every source file. For the first pass, I've just added myself for simplicity. I encourage everyone to add themselves as copyright holders of any file they've added or modified in some significant way. If I've added myself in error somewhere, feel free to replace it with the appropriate copyright holder instead. Going forward, all new source files should include a license header.
2020-01-18 09:38:21 +01:00
/*
* Copyright (c) 2018-2020, Andreas Kling <kling@serenityos.org>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
* CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
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. :^)
2019-12-30 18:46:17 +01:00
#include <AK/QuickSort.h>
Kernel: Clean up around Scheduler::yield() a bit. Also add assertion in Lock that the scheduler isn't currently active. I've been seeing occasional fuckups that I suspect might be someone called by the scheduler trying to take a busy lock.
2019-02-06 15:05:47 +01:00
#include <AK/TemporaryChange.h>
Kernel: Run clang-format on everything.
2019-06-07 11:43:58 +02:00
#include <Kernel/FileSystem/FileDescription.h>
Kernel: Move all code into the Kernel namespace
2020-02-16 01:27:42 +01:00
#include <Kernel/Net/Socket.h>
Kernel: Qualify a bunch of #include statements.
2019-06-07 19:29:34 +02:00
#include <Kernel/Process.h>
Kernel: Implement a simple process time profiler The kernel now supports basic profiling of all the threads in a process by calling profiling_enable(pid_t). You finish the profiling by calling profiling_disable(pid_t). This all works by recording thread stacks when the timer interrupt fires and the current thread is in a process being profiled. Note that symbolication is deferred until profiling_disable() to avoid adding more noise than necessary to the profile. A simple "/bin/profile" command is included here that can be used to start/stop profiling like so: $ profile 10 on ... wait ... $ profile 10 off After a profile has been recorded, it can be fetched in /proc/profile There are various limits (or "bugs") on this mechanism at the moment: - Only one process can be profiled at a time. - We allocate 8MB for the samples, if you use more space, things will not work, and probably break a bit. - Things will probably fall apart if the profiled process dies during profiling, or while extracing /proc/profile
2019-12-11 20:36:56 +01:00
#include <Kernel/Profiling.h>
Kernel: Qualify a bunch of #include statements.
2019-06-07 19:29:34 +02:00
#include <Kernel/RTC.h>
#include <Kernel/Scheduler.h>
Kernel: Introduce the new Time management subsystem This new subsystem includes better abstractions of how time will be handled in the OS. We take advantage of the existing RTC timer to aid in keeping time synchronized. This is standing in contrast to how we handled time-keeping in the kernel, where the PIT was responsible for that function in addition to update the scheduler about ticks. With that new advantage, we can easily change the ticking dynamically and still keep the time synchronized. In the process context, we no longer use a fixed declaration of TICKS_PER_SECOND, but we call the TimeManagement singleton class to provide us the right value. This allows us to use dynamic ticking in the future, a feature known as tickless kernel. The scheduler no longer does by himself the calculation of real time (Unix time), and just calls the TimeManagment singleton class to provide the value. Also, we can use 2 new boot arguments: - the "time" boot argument accpets either the value "modern", or "legacy". If "modern" is specified, the time management subsystem will try to setup HPET. Otherwise, for "legacy" value, the time subsystem will revert to use the PIT & RTC, leaving HPET disabled. If this boot argument is not specified, the default pattern is to try to setup HPET. - the "hpet" boot argumet accepts either the value "periodic" or "nonperiodic". If "periodic" is specified, the HPET will scan for periodic timers, and will assert if none are found. If only one is found, that timer will be assigned for the time-keeping task. If more than one is found, both time-keeping task & scheduler-ticking task will be assigned to periodic timers. If this boot argument is not specified, the default pattern is to try to scan for HPET periodic timers. This boot argument has no effect if HPET is disabled. In hardware context, PIT & RealTimeClock classes are merely inheriting from the HardwareTimer class, and they allow to use the old i8254 (PIT) and RTC devices, managing them via IO ports. By default, the RTC will be programmed to a frequency of 1024Hz. The PIT will be programmed to a frequency close to 1000Hz. About HPET, depending if we need to scan for periodic timers or not, we try to set a frequency close to 1000Hz for the time-keeping timer and scheduler-ticking timer. Also, if possible, we try to enable the Legacy replacement feature of the HPET. This feature if exists, instructs the chipset to disconnect both i8254 (PIT) and RTC. This behavior is observable on QEMU, and was verified against the source code: https://github.com/qemu/qemu/commit/ce967e2f33861b0e17753f97fa4527b5943c94b6 The HPETComparator class is inheriting from HardwareTimer class, and is responsible for an individual HPET comparator, which is essentially a timer. Therefore, it needs to call the singleton HPET class to perform HPET-related operations. The new abstraction of Hardware timers brings an opportunity of more new features in the foreseeable future. For example, we can change the callback function of each hardware timer, thus it makes it possible to swap missions between hardware timers, or to allow to use a hardware timer for other temporary missions (e.g. calibrating the LAPIC timer, measuring the CPU frequency, etc).
2020-03-09 17:03:27 +02:00
#include <Kernel/Time/TimeManagement.h>
Kernel: Add kernel-level timer queue (heavily based on @juliusf's work) PR #591 defines the rationale for kernel-level timers. They're most immediately useful for TCP retransmission, but will most likely see use in many other areas as well.
2019-12-27 11:58:28 +11:00
#include <Kernel/TimerQueue.h>
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
Kernel: Separate runnable thread queues by priority This patch introduces three separate thread queues, one for each thread priority available to userspace (Low, Normal and High.) Each queue operates in a round-robin fashion, but we now always prefer to schedule the highest priority thread that currently wants to run. There are tons of tweaks and improvements that we can and should make to this mechanism, but I think this is a step in the right direction. This makes WindowServer significantly more responsive while one of its clients is burning CPU. :^)
2019-12-27 00:46:38 +01:00
//#define LOG_EVERY_CONTEXT_SWITCH
//#define SCHEDULER_DEBUG
//#define SCHEDULER_RUNNABLE_DEBUG
Kernel: Move all code into the Kernel namespace
2020-02-16 01:27:42 +01:00
namespace Kernel {
Kernel: Don't create Function objects in the scheduling code Each Function is a heap allocation, so let's make an effort to avoid doing that during scheduling. Because of header dependencies, I had to put the runnables iteration helpers in Thread.h, which is a bit meh but at least this cuts out all the kmalloc() traffic in pick_next().
2019-08-07 20:43:54 +02:00
SchedulerData* g_scheduler_data;
Kernel: Remove the "kernel info page" used for fast gettimeofday() We stopped using gettimeofday() in Core::EventLoop a while back, in favor of clock_gettime() for monotonic time. Maintaining an optimization for a syscall we're not using doesn't make a lot of sense, so let's go back to the old-style sys$gettimeofday().
2020-05-16 11:18:04 +02:00
timeval g_timeofday;
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
RecursiveSpinLock g_scheduler_lock;
Move runnable/non-runnable list control entirely over to Scheduler This way, we can change how the scheduler works without having to change Thread too.
2019-07-19 17:21:13 +02:00
void Scheduler::init_thread(Thread& thread)
{
Kernel: Boot all APS all the way into their own idle loop
2020-06-28 22:36:12 -06:00
ASSERT(g_scheduler_data);
Move runnable/non-runnable list control entirely over to Scheduler This way, we can change how the scheduler works without having to change Thread too.
2019-07-19 17:21:13 +02:00
g_scheduler_data->m_nonrunnable_threads.append(thread);
}
void Scheduler::update_state_for_thread(Thread& thread)
{
Kernel: Separate runnable thread queues by priority This patch introduces three separate thread queues, one for each thread priority available to userspace (Low, Normal and High.) Each queue operates in a round-robin fashion, but we now always prefer to schedule the highest priority thread that currently wants to run. There are tons of tweaks and improvements that we can and should make to this mechanism, but I think this is a step in the right direction. This makes WindowServer significantly more responsive while one of its clients is burning CPU. :^)
2019-12-27 00:46:38 +01:00
ASSERT_INTERRUPTS_DISABLED();
Kernel: Boot all APS all the way into their own idle loop
2020-06-28 22:36:12 -06:00
ASSERT(g_scheduler_data);
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. :^)
2019-12-30 18:46:17 +01:00
auto& list = g_scheduler_data->thread_list_for_state(thread.state());
Move runnable/non-runnable list control entirely over to Scheduler This way, we can change how the scheduler works without having to change Thread too.
2019-07-19 17:21:13 +02:00
if (list.contains(thread))
return;
list.append(thread);
}
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. :^)
2019-12-30 18:46:17 +01:00
static u32 time_slice_for(const Thread& thread)
Kernel: Add basic process priority support. For now, the WindowServer process will run with high priority, while the Finalizer process will run with low priority. Everyone else gets to be "normal". At the moment, priority simply determines the size of your time slices.
2019-02-07 12:21:17 +01:00
{
// One time slice unit == 1ms
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
if (&thread == Processor::current().idle_thread())
Kernel: Make the colonel run at "Idle" priority (the lowest possible.) This means it won't hog the CPU for more than a single timeslice. :^)
2019-04-20 15:58:45 +02:00
return 1;
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. :^)
2019-12-30 18:46:17 +01:00
return 10;
Kernel: Add basic process priority support. For now, the WindowServer process will run with high priority, while the Finalizer process will run with low priority. Everyone else gets to be "normal". At the moment, priority simply determines the size of your time slices.
2019-02-07 12:21:17 +01:00
}
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
Scheduler: Use monotonic time for blocking threads
2020-03-14 00:59:45 +02:00
timeval Scheduler::time_since_boot()
{
return { TimeManagement::the().seconds_since_boot(), (suseconds_t)TimeManagement::the().ticks_this_second() * 1000 };
}
Kernel: Introduce threads, and refactor everything in support of it. The scheduler now operates on threads, rather than on processes. Each process has a main thread, and can have any number of additional threads. The process exits when the main thread exits. This patch doesn't actually spawn any additional threads, it merely does all the plumbing needed to make it possible. :^)
2019-03-23 22:03:17 +01:00
Thread* g_finalizer;
Kernel: Use a WaitQueue to implement finalizer wakeup This gets rid of the special "Lurking" thread state and replaces it with a generic WaitQueue :^)
2019-12-01 19:17:17 +01:00
WaitQueue* g_finalizer_wait_queue;
Kernel: Implement software context switching and Processor structure Moving certain globals into a new Processor structure for each CPU allows us to eventually run an instance of the scheduler on each CPU.
2020-06-27 13:42:28 -06:00
Atomic<bool> g_finalizer_has_work{false};
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
static Process* s_colonel_process;
AK: Rename the common integer typedefs to make it obvious what they are. These types can be picked up by including <AK/Types.h>: * u8, u16, u32, u64 (unsigned) * i8, i16, i32, i64 (signed)
2019-07-03 21:17:35 +02:00
u64 g_uptime;
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
Kernel: Move Thread::m_joinee_exit_value into the JoinBlocker There's no need for this to be a permanent Thread member. Just use a reference in the JoinBlocker instead.
2019-11-14 21:04:34 +01:00
Thread::JoinBlocker::JoinBlocker(Thread& joinee, void*& joinee_exit_value)
Kernel+LibPthread: Implement pthread_join() It's now possible to block until another thread in the same process has exited. We can also retrieve its exit value, which is whatever value it passed to pthread_exit(). :^)
2019-11-14 20:58:23 +01:00
: m_joinee(joinee)
Kernel: Move Thread::m_joinee_exit_value into the JoinBlocker There's no need for this to be a permanent Thread member. Just use a reference in the JoinBlocker instead.
2019-11-14 21:04:34 +01:00
, m_joinee_exit_value(joinee_exit_value)
Kernel+LibPthread: Implement pthread_join() It's now possible to block until another thread in the same process has exited. We can also retrieve its exit value, which is whatever value it passed to pthread_exit(). :^)
2019-11-14 20:58:23 +01:00
{
ASSERT(m_joinee.m_joiner == nullptr);
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
auto current_thread = Thread::current();
m_joinee.m_joiner = current_thread;
current_thread->m_joinee = &joinee;
Kernel+LibPthread: Implement pthread_join() It's now possible to block until another thread in the same process has exited. We can also retrieve its exit value, which is whatever value it passed to pthread_exit(). :^)
2019-11-14 20:58:23 +01:00
}
bool Thread::JoinBlocker::should_unblock(Thread& joiner, time_t, long)
{
return !joiner.m_joinee;
}
Kernel: Some small refinements to the thread blockers. Committing some things my hands did while browsing through this code. - Mark all leaf classes "final". - FileDescriptionBlocker now stores a NonnullRefPtr<FileDescription>. - FileDescriptionBlocker::blocked_description() now returns a reference. - ConditionBlocker takes a Function&&.
2019-07-19 13:19:47 +02:00
Thread::FileDescriptionBlocker::FileDescriptionBlocker(const FileDescription& description)
Kernel: Introduce ThreadBlocker as a way to make unblocking neater :) And port all the descriptor-based blocks over to it as a proof of concept.
2019-07-18 16:22:26 +02:00
: m_blocked_description(description)
Kernel: Add a WaitQueue for Thread queueing/waking and use it for Lock The kernel's Lock class now uses a proper wait queue internally instead of just having everyone wake up regularly to try to acquire the lock. We also keep the donation mechanism, so that whenever someone tries to take the lock and fails, that thread donates the remainder of its timeslice to the current lock holder. After unlocking a Lock, the unlocking thread calls WaitQueue::wake_one, which unblocks the next thread in queue.
2019-12-01 11:57:20 +01:00
{
}
Kernel: Introduce ThreadBlocker as a way to make unblocking neater :) And port all the descriptor-based blocks over to it as a proof of concept.
2019-07-18 16:22:26 +02:00
Kernel: Some small refinements to the thread blockers. Committing some things my hands did while browsing through this code. - Mark all leaf classes "final". - FileDescriptionBlocker now stores a NonnullRefPtr<FileDescription>. - FileDescriptionBlocker::blocked_description() now returns a reference. - ConditionBlocker takes a Function&&.
2019-07-19 13:19:47 +02:00
const FileDescription& Thread::FileDescriptionBlocker::blocked_description() const
Kernel: Introduce ThreadBlocker as a way to make unblocking neater :) And port all the descriptor-based blocks over to it as a proof of concept.
2019-07-18 16:22:26 +02:00
{
return m_blocked_description;
}
Kernel: Some small refinements to the thread blockers. Committing some things my hands did while browsing through this code. - Mark all leaf classes "final". - FileDescriptionBlocker now stores a NonnullRefPtr<FileDescription>. - FileDescriptionBlocker::blocked_description() now returns a reference. - ConditionBlocker takes a Function&&.
2019-07-19 13:19:47 +02:00
Thread::AcceptBlocker::AcceptBlocker(const FileDescription& description)
Kernel: Rename ThreadBlocker classes to avoid stutter Thread::ThreadBlockerFoo is a lot less nice to read than Thread::FooBlocker
2019-07-18 18:12:37 +02:00
: FileDescriptionBlocker(description)
Kernel: Introduce ThreadBlocker as a way to make unblocking neater :) And port all the descriptor-based blocks over to it as a proof of concept.
2019-07-18 16:22:26 +02:00
{
}
Kernel: Rename ThreadBlocker classes to avoid stutter Thread::ThreadBlockerFoo is a lot less nice to read than Thread::FooBlocker
2019-07-18 18:12:37 +02:00
bool Thread::AcceptBlocker::should_unblock(Thread&, time_t, long)
Kernel: Introduce ThreadBlocker as a way to make unblocking neater :) And port all the descriptor-based blocks over to it as a proof of concept.
2019-07-18 16:22:26 +02:00
{
Kernel: Some small refinements to the thread blockers. Committing some things my hands did while browsing through this code. - Mark all leaf classes "final". - FileDescriptionBlocker now stores a NonnullRefPtr<FileDescription>. - FileDescriptionBlocker::blocked_description() now returns a reference. - ConditionBlocker takes a Function&&.
2019-07-19 13:19:47 +02:00
auto& socket = *blocked_description().socket();
Kernel: Introduce ThreadBlocker as a way to make unblocking neater :) And port all the descriptor-based blocks over to it as a proof of concept.
2019-07-18 16:22:26 +02:00
return socket.can_accept();
}
Kernel: Some small refinements to the thread blockers. Committing some things my hands did while browsing through this code. - Mark all leaf classes "final". - FileDescriptionBlocker now stores a NonnullRefPtr<FileDescription>. - FileDescriptionBlocker::blocked_description() now returns a reference. - ConditionBlocker takes a Function&&.
2019-07-19 13:19:47 +02:00
Thread::ConnectBlocker::ConnectBlocker(const FileDescription& description)
Kernel: Rename ThreadBlocker classes to avoid stutter Thread::ThreadBlockerFoo is a lot less nice to read than Thread::FooBlocker
2019-07-18 18:12:37 +02:00
: FileDescriptionBlocker(description)
Kernel: Introduce ThreadBlocker as a way to make unblocking neater :) And port all the descriptor-based blocks over to it as a proof of concept.
2019-07-18 16:22:26 +02:00
{
}
Kernel: Rename ThreadBlocker classes to avoid stutter Thread::ThreadBlockerFoo is a lot less nice to read than Thread::FooBlocker
2019-07-18 18:12:37 +02:00
bool Thread::ConnectBlocker::should_unblock(Thread&, time_t, long)
Kernel: Introduce ThreadBlocker as a way to make unblocking neater :) And port all the descriptor-based blocks over to it as a proof of concept.
2019-07-18 16:22:26 +02:00
{
Kernel: Some small refinements to the thread blockers. Committing some things my hands did while browsing through this code. - Mark all leaf classes "final". - FileDescriptionBlocker now stores a NonnullRefPtr<FileDescription>. - FileDescriptionBlocker::blocked_description() now returns a reference. - ConditionBlocker takes a Function&&.
2019-07-19 13:19:47 +02:00
auto& socket = *blocked_description().socket();
Kernel: Use a more detailed state machine for socket setup
2019-08-10 13:17:00 +10:00
return socket.setup_state() == Socket::SetupState::Completed;
Kernel: Introduce ThreadBlocker as a way to make unblocking neater :) And port all the descriptor-based blocks over to it as a proof of concept.
2019-07-18 16:22:26 +02:00
}
Kernel: Some small refinements to the thread blockers. Committing some things my hands did while browsing through this code. - Mark all leaf classes "final". - FileDescriptionBlocker now stores a NonnullRefPtr<FileDescription>. - FileDescriptionBlocker::blocked_description() now returns a reference. - ConditionBlocker takes a Function&&.
2019-07-19 13:19:47 +02:00
Thread::WriteBlocker::WriteBlocker(const FileDescription& description)
Kernel: Rename ThreadBlocker classes to avoid stutter Thread::ThreadBlockerFoo is a lot less nice to read than Thread::FooBlocker
2019-07-18 18:12:37 +02:00
: FileDescriptionBlocker(description)
Kernel: Introduce ThreadBlocker as a way to make unblocking neater :) And port all the descriptor-based blocks over to it as a proof of concept.
2019-07-18 16:22:26 +02:00
{
Kernel: read()/write() should respect timeouts when used on a sockets Move timeout management to the ReadBlocker and WriteBlocker classes. Also get rid of the specialized ReceiveBlocker since it no longer does anything that ReadBlocker can't do.
2020-01-26 17:54:23 +01:00
if (description.is_socket()) {
auto& socket = *description.socket();
if (socket.has_send_timeout()) {
Scheduler: Use monotonic time for blocking threads
2020-03-14 00:59:45 +02:00
timeval deadline = Scheduler::time_since_boot();
Kernel: read()/write() should respect timeouts when used on a sockets Move timeout management to the ReadBlocker and WriteBlocker classes. Also get rid of the specialized ReceiveBlocker since it no longer does anything that ReadBlocker can't do.
2020-01-26 17:54:23 +01:00
deadline.tv_sec += socket.send_timeout().tv_sec;
deadline.tv_usec += socket.send_timeout().tv_usec;
deadline.tv_sec += (socket.send_timeout().tv_usec / 1000000) * 1;
deadline.tv_usec %= 1000000;
m_deadline = deadline;
}
}
}
bool Thread::WriteBlocker::should_unblock(Thread&, time_t now_sec, long now_usec)
{
if (m_deadline.has_value()) {
bool timed_out = now_sec > m_deadline.value().tv_sec || (now_sec == m_deadline.value().tv_sec && now_usec >= m_deadline.value().tv_usec);
return timed_out || blocked_description().can_write();
}
Kernel: Some small refinements to the thread blockers. Committing some things my hands did while browsing through this code. - Mark all leaf classes "final". - FileDescriptionBlocker now stores a NonnullRefPtr<FileDescription>. - FileDescriptionBlocker::blocked_description() now returns a reference. - ConditionBlocker takes a Function&&.
2019-07-19 13:19:47 +02:00
return blocked_description().can_write();
Kernel: Introduce ThreadBlocker as a way to make unblocking neater :) And port all the descriptor-based blocks over to it as a proof of concept.
2019-07-18 16:22:26 +02:00
}
Kernel: Some small refinements to the thread blockers. Committing some things my hands did while browsing through this code. - Mark all leaf classes "final". - FileDescriptionBlocker now stores a NonnullRefPtr<FileDescription>. - FileDescriptionBlocker::blocked_description() now returns a reference. - ConditionBlocker takes a Function&&.
2019-07-19 13:19:47 +02:00
Thread::ReadBlocker::ReadBlocker(const FileDescription& description)
Kernel: Rename ThreadBlocker classes to avoid stutter Thread::ThreadBlockerFoo is a lot less nice to read than Thread::FooBlocker
2019-07-18 18:12:37 +02:00
: FileDescriptionBlocker(description)
Kernel: Introduce ThreadBlocker as a way to make unblocking neater :) And port all the descriptor-based blocks over to it as a proof of concept.
2019-07-18 16:22:26 +02:00
{
Kernel: read()/write() should respect timeouts when used on a sockets Move timeout management to the ReadBlocker and WriteBlocker classes. Also get rid of the specialized ReceiveBlocker since it no longer does anything that ReadBlocker can't do.
2020-01-26 17:54:23 +01:00
if (description.is_socket()) {
auto& socket = *description.socket();
if (socket.has_receive_timeout()) {
Scheduler: Use monotonic time for blocking threads
2020-03-14 00:59:45 +02:00
timeval deadline = Scheduler::time_since_boot();
Kernel: read()/write() should respect timeouts when used on a sockets Move timeout management to the ReadBlocker and WriteBlocker classes. Also get rid of the specialized ReceiveBlocker since it no longer does anything that ReadBlocker can't do.
2020-01-26 17:54:23 +01:00
deadline.tv_sec += socket.receive_timeout().tv_sec;
deadline.tv_usec += socket.receive_timeout().tv_usec;
deadline.tv_sec += (socket.receive_timeout().tv_usec / 1000000) * 1;
deadline.tv_usec %= 1000000;
m_deadline = deadline;
}
}
}
bool Thread::ReadBlocker::should_unblock(Thread&, time_t now_sec, long now_usec)
{
if (m_deadline.has_value()) {
bool timed_out = now_sec > m_deadline.value().tv_sec || (now_sec == m_deadline.value().tv_sec && now_usec >= m_deadline.value().tv_usec);
return timed_out || blocked_description().can_read();
}
Kernel: Some small refinements to the thread blockers. Committing some things my hands did while browsing through this code. - Mark all leaf classes "final". - FileDescriptionBlocker now stores a NonnullRefPtr<FileDescription>. - FileDescriptionBlocker::blocked_description() now returns a reference. - ConditionBlocker takes a Function&&.
2019-07-19 13:19:47 +02:00
return blocked_description().can_read();
Kernel: Introduce ThreadBlocker as a way to make unblocking neater :) And port all the descriptor-based blocks over to it as a proof of concept.
2019-07-18 16:22:26 +02:00
}
Kernel: Some small refinements to the thread blockers. Committing some things my hands did while browsing through this code. - Mark all leaf classes "final". - FileDescriptionBlocker now stores a NonnullRefPtr<FileDescription>. - FileDescriptionBlocker::blocked_description() now returns a reference. - ConditionBlocker takes a Function&&.
2019-07-19 13:19:47 +02:00
Thread::ConditionBlocker::ConditionBlocker(const char* state_string, Function<bool()>&& condition)
Kernel: Introduce ThreadBlocker as a way to make unblocking neater :) And port all the descriptor-based blocks over to it as a proof of concept.
2019-07-18 16:22:26 +02:00
: m_block_until_condition(move(condition))
Kernel: Restore state strings for block states "Blocking" is not terribly informative, but now that everything is ported over, we can force the blocker to provide us with a reason. This does mean that to_string(State) needed to become a member, but that's OK.
2019-07-19 09:51:48 +02:00
, m_state_string(state_string)
Kernel: Introduce ThreadBlocker as a way to make unblocking neater :) And port all the descriptor-based blocks over to it as a proof of concept.
2019-07-18 16:22:26 +02:00
{
ASSERT(m_block_until_condition);
}
Kernel: Rename ThreadBlocker classes to avoid stutter Thread::ThreadBlockerFoo is a lot less nice to read than Thread::FooBlocker
2019-07-18 18:12:37 +02:00
bool Thread::ConditionBlocker::should_unblock(Thread&, time_t, long)
Kernel: Introduce ThreadBlocker as a way to make unblocking neater :) And port all the descriptor-based blocks over to it as a proof of concept.
2019-07-18 16:22:26 +02:00
{
return m_block_until_condition();
}
Kernel: Rename ThreadBlocker classes to avoid stutter Thread::ThreadBlockerFoo is a lot less nice to read than Thread::FooBlocker
2019-07-18 18:12:37 +02:00
Thread::SleepBlocker::SleepBlocker(u64 wakeup_time)
Kernel: Port sleep to ThreadBlocker
2019-07-18 17:26:11 +02:00
: m_wakeup_time(wakeup_time)
{
}
Kernel: Rename ThreadBlocker classes to avoid stutter Thread::ThreadBlockerFoo is a lot less nice to read than Thread::FooBlocker
2019-07-18 18:12:37 +02:00
bool Thread::SleepBlocker::should_unblock(Thread&, time_t, long)
Kernel: Port sleep to ThreadBlocker
2019-07-18 17:26:11 +02:00
{
return m_wakeup_time <= g_uptime;
}
LibC: Implement pselect pselect() is similar() to select(), but it takes its timeout as timespec instead of as timeval, and it takes an additional sigmask parameter. Change the sys$select parameters to match pselect() and implement select() in terms of pselect().
2020-06-21 13:54:41 -04:00
Thread::SelectBlocker::SelectBlocker(const timespec& ts, bool select_has_timeout, const FDVector& read_fds, const FDVector& write_fds, const FDVector& except_fds)
: m_select_timeout(ts)
Kernel: Port select to ThreadBlocker
2019-07-18 17:39:49 +02:00
, m_select_has_timeout(select_has_timeout)
, m_select_read_fds(read_fds)
, m_select_write_fds(write_fds)
, m_select_exceptional_fds(except_fds)
{
}
Kernel: Rename ThreadBlocker classes to avoid stutter Thread::ThreadBlockerFoo is a lot less nice to read than Thread::FooBlocker
2019-07-18 18:12:37 +02:00
bool Thread::SelectBlocker::should_unblock(Thread& thread, time_t now_sec, long now_usec)
Kernel: Port select to ThreadBlocker
2019-07-18 17:39:49 +02:00
{
if (m_select_has_timeout) {
LibC: Implement pselect pselect() is similar() to select(), but it takes its timeout as timespec instead of as timeval, and it takes an additional sigmask parameter. Change the sys$select parameters to match pselect() and implement select() in terms of pselect().
2020-06-21 13:54:41 -04:00
if (now_sec > m_select_timeout.tv_sec || (now_sec == m_select_timeout.tv_sec && now_usec * 1000 >= m_select_timeout.tv_nsec))
Kernel: Port select to ThreadBlocker
2019-07-18 17:39:49 +02:00
return true;
}
auto& process = thread.process();
for (int fd : m_select_read_fds) {
Kernel: Ignore closed fd's when considering select() unblock This fixes a null RefPtr deref (which asserts) in the scheduler if a file descriptor being select()'ed is closed by a second thread while blocked in select(). Test: Kernel/null-deref-close-during-select.cpp
2020-01-09 12:36:42 +01:00
if (!process.m_fds[fd])
continue;
Kernel: Port select to ThreadBlocker
2019-07-18 17:39:49 +02:00
if (process.m_fds[fd].description->can_read())
return true;
}
for (int fd : m_select_write_fds) {
Kernel: Ignore closed fd's when considering select() unblock This fixes a null RefPtr deref (which asserts) in the scheduler if a file descriptor being select()'ed is closed by a second thread while blocked in select(). Test: Kernel/null-deref-close-during-select.cpp
2020-01-09 12:36:42 +01:00
if (!process.m_fds[fd])
continue;
Kernel: Port select to ThreadBlocker
2019-07-18 17:39:49 +02:00
if (process.m_fds[fd].description->can_write())
return true;
}
return false;
}
Kernel: Rename ThreadBlocker classes to avoid stutter Thread::ThreadBlockerFoo is a lot less nice to read than Thread::FooBlocker
2019-07-18 18:12:37 +02:00
Thread::WaitBlocker::WaitBlocker(int wait_options, pid_t& waitee_pid)
Kernel: Port wait to ThreadBlocker
2019-07-18 18:05:19 +02:00
: m_wait_options(wait_options)
, m_waitee_pid(waitee_pid)
{
}
Kernel: Rename ThreadBlocker classes to avoid stutter Thread::ThreadBlockerFoo is a lot less nice to read than Thread::FooBlocker
2019-07-18 18:12:37 +02:00
bool Thread::WaitBlocker::should_unblock(Thread& thread, time_t, long)
Kernel: Port wait to ThreadBlocker
2019-07-18 18:05:19 +02:00
{
Kernel: WaitBlocker should always unblock immediately on WNOHANG This fixes a problem where we'd block if a process with no children would call sys$waitid() with WNOHANG. This unbreaks bash :^)
2020-05-18 13:05:25 +02:00
bool should_unblock = m_wait_options & WNOHANG;
Kernel: waitpid() should unblock and -ECHILD if SIG_IGN reaps child
2019-09-08 13:54:48 +02:00
if (m_waitee_pid != -1) {
auto* peer = Process::from_pid(m_waitee_pid);
if (!peer)
return true;
}
Kernel: Port wait to ThreadBlocker
2019-07-18 18:05:19 +02:00
thread.process().for_each_child([&](Process& child) {
if (m_waitee_pid != -1 && m_waitee_pid != child.pid())
return IterationDecision::Continue;
bool child_exited = child.is_dead();
WaitBlocker: don't unblock if thread has pending SIGCONT Previosuly, if we sent a SIGCONT to a stopped thread and then waitpid() with WSTOPPED on that thread before the signal was dispatched, then the WaitBlocker would first unblock (because the thread is stopped) and only after that the thread would get the SIGCONT signal. This would mean that when waitpid returns the waitee is not stopped. To fix this, we do not unblock the waiting thread if the waitee thread has a pending SIGCONT.
2020-03-28 11:03:43 +03:00
bool child_stopped = false;
if (child.thread_count()) {
Kernel: Let the wait blocker inspect *all* child threads of a process Previously would only grab the first thread in the thread list that had the same PID as our waitee and check if it was stopped.
2020-05-16 12:38:24 +02:00
child.for_each_thread([&](auto& child_thread) {
if (child_thread.state() == Thread::State::Stopped && !child_thread.has_pending_signal(SIGCONT)) {
child_stopped = true;
return IterationDecision::Break;
}
return IterationDecision::Continue;
});
WaitBlocker: don't unblock if thread has pending SIGCONT Previosuly, if we sent a SIGCONT to a stopped thread and then waitpid() with WSTOPPED on that thread before the signal was dispatched, then the WaitBlocker would first unblock (because the thread is stopped) and only after that the thread would get the SIGCONT signal. This would mean that when waitpid returns the waitee is not stopped. To fix this, we do not unblock the waiting thread if the waitee thread has a pending SIGCONT.
2020-03-28 11:03:43 +03:00
}
Kernel: Port wait to ThreadBlocker
2019-07-18 18:05:19 +02:00
Kernel: Fix returning random children from waitid(WNOHANG) In case WNOHANG was specified, we want to always set should_unblock to true (which we do since commit 4402207b983b6ad4e317ef5affa4a78f10903a26), not wait_finished -- the latter causes us to immediately return this child to our caller, which is not what we want -- perhaps we should return another child which has actually exited or stopped, or nobody at all. To avoid confusion, also rename wait_finished to fits_the_spec. This fixes service keepalive functionality in SystemServer.
2020-05-25 13:23:41 +03:00
bool fits_the_spec = ((m_wait_options & WEXITED) && child_exited)
|| ((m_wait_options & WSTOPPED) && child_stopped);
Kernel: Port wait to ThreadBlocker
2019-07-18 18:05:19 +02:00
Kernel: Fix returning random children from waitid(WNOHANG) In case WNOHANG was specified, we want to always set should_unblock to true (which we do since commit 4402207b983b6ad4e317ef5affa4a78f10903a26), not wait_finished -- the latter causes us to immediately return this child to our caller, which is not what we want -- perhaps we should return another child which has actually exited or stopped, or nobody at all. To avoid confusion, also rename wait_finished to fits_the_spec. This fixes service keepalive functionality in SystemServer.
2020-05-25 13:23:41 +03:00
if (!fits_the_spec)
Kernel: Port wait to ThreadBlocker
2019-07-18 18:05:19 +02:00
return IterationDecision::Continue;
m_waitee_pid = child.pid();
should_unblock = true;
return IterationDecision::Break;
});
return should_unblock;
}
Kernel: Convert BlockedSignal and BlockedLurking to the new Blocker mechanism The last two of the old block states gone :)
2019-07-19 09:34:11 +02:00
Thread::SemiPermanentBlocker::SemiPermanentBlocker(Reason reason)
: m_reason(reason)
Kernel: Add a WaitQueue for Thread queueing/waking and use it for Lock The kernel's Lock class now uses a proper wait queue internally instead of just having everyone wake up regularly to try to acquire the lock. We also keep the donation mechanism, so that whenever someone tries to take the lock and fails, that thread donates the remainder of its timeslice to the current lock holder. After unlocking a Lock, the unlocking thread calls WaitQueue::wake_one, which unblocks the next thread in queue.
2019-12-01 11:57:20 +01:00
{
}
Kernel: Convert BlockedSignal and BlockedLurking to the new Blocker mechanism The last two of the old block states gone :)
2019-07-19 09:34:11 +02:00
bool Thread::SemiPermanentBlocker::should_unblock(Thread&, time_t, long)
{
// someone else has to unblock us
return false;
}
Scheduler: Move thread unblocking out of a lambda to help make things more readable We also use a switch to explicitly make sure we handle all cases properly.
2019-07-18 14:10:28 +02:00
// Called by the scheduler on threads that are blocked for some reason.
// Make a decision as to whether to unblock them or not.
void Thread::consider_unblock(time_t now_sec, long now_usec)
{
switch (state()) {
case Thread::Invalid:
case Thread::Runnable:
case Thread::Running:
case Thread::Dead:
case Thread::Stopped:
Kernel: Use a dedicated thread state for wait-queued threads Instead of using the generic block mechanism, wait-queued threads now go into the special Queued state. This fixes an issue where signal dispatch would unblock a wait-queued thread (because signal dispatch unblocks blocked threads) and cause confusion since the thread only expected to be awoken by the queue.
2019-12-01 15:54:47 +01:00
case Thread::Queued:
Kernel: Use a WaitQueue to implement finalizer wakeup This gets rid of the special "Lurking" thread state and replaces it with a generic WaitQueue :^)
2019-12-01 19:17:17 +01:00
case Thread::Dying:
Scheduler: Move thread unblocking out of a lambda to help make things more readable We also use a switch to explicitly make sure we handle all cases properly.
2019-07-18 14:10:28 +02:00
/* don't know, don't care */
return;
Kernel: Rename Condition state to Blocked now we only have one blocking mechanism :)
2019-07-19 09:37:34 +02:00
case Thread::Blocked:
Kernel: Change m_blockers to m_blocker. Because of the way signals now work there should not be more than one blocker per thread. This changes the blocker and thread class to reflect that.
2019-09-09 15:58:42 +12:00
ASSERT(m_blocker != nullptr);
if (m_blocker->should_unblock(*this, now_sec, now_usec))
Scheduler: Move thread unblocking out of a lambda to help make things more readable We also use a switch to explicitly make sure we handle all cases properly.
2019-07-18 14:10:28 +02:00
unblock();
return;
case Thread::Skip1SchedulerPass:
set_state(Thread::Skip0SchedulerPasses);
return;
case Thread::Skip0SchedulerPasses:
set_state(Thread::Runnable);
return;
}
}
Kernel: Implement software context switching and Processor structure Moving certain globals into a new Processor structure for each CPU allows us to eventually run an instance of the scheduler on each CPU.
2020-06-27 13:42:28 -06:00
void Scheduler::start()
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
{
ASSERT_INTERRUPTS_DISABLED();
Kernel: Various context switch fixes These changes solve a number of problems with the software context swithcing: * The scheduler lock really should be held throughout context switches * Transitioning from the initial (idle) thread to another needs to hold the scheduler lock * Transitioning from a dying thread to another also needs to hold the scheduler lock * Dying threads cannot necessarily be finalized if they haven't switched out of it yet, so flag them as active while a processor is running it (the Running state may be switched to Dying while it still is actually running)
2020-07-05 14:32:07 -06:00
// We need to acquire our scheduler lock, which will be released
// by the idle thread once control transferred there
g_scheduler_lock.lock();
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
auto& processor = Processor::current();
Kernel: Boot all APS all the way into their own idle loop
2020-06-28 22:36:12 -06:00
ASSERT(processor.is_initialized());
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
auto& idle_thread = *processor.idle_thread();
Kernel: Boot all APS all the way into their own idle loop
2020-06-28 22:36:12 -06:00
ASSERT(processor.current_thread() == &idle_thread);
ASSERT(processor.idle_thread() == &idle_thread);
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
idle_thread.set_ticks_left(time_slice_for(idle_thread));
idle_thread.did_schedule();
idle_thread.set_initialized(true);
Kernel: Fix signal delivery When delivering urgent signals to the current thread we need to check if we should be unblocked, and if not we need to yield to another process. We also need to make sure that we suppress context switches during Process::exec() so that we don't clobber the registers that it sets up (eip mainly) by a context switch. To be able to do that we add the concept of a critical section, which are similar to Process::m_in_irq but different in that they can be requested at any time. Calls to Scheduler::yield and Scheduler::donate_to will return instantly without triggering a context switch, but the processor will then asynchronously trigger a context switch once the critical section is left.
2020-07-03 05:19:50 -06:00
processor.init_context(idle_thread, false);
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
idle_thread.set_state(Thread::Running);
Kernel: Boot all APS all the way into their own idle loop
2020-06-28 22:36:12 -06:00
ASSERT(idle_thread.affinity() == (1u << processor.id()));
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
processor.initialize_context_switching(idle_thread);
Kernel: Implement software context switching and Processor structure Moving certain globals into a new Processor structure for each CPU allows us to eventually run an instance of the scheduler on each CPU.
2020-06-27 13:42:28 -06:00
ASSERT_NOT_REACHED();
}
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
Kernel: Implement software context switching and Processor structure Moving certain globals into a new Processor structure for each CPU allows us to eventually run an instance of the scheduler on each CPU.
2020-06-27 13:42:28 -06:00
bool Scheduler::pick_next()
{
ASSERT_INTERRUPTS_DISABLED();
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
auto current_thread = Thread::current();
Scheduler: Use monotonic time for blocking threads
2020-03-14 00:59:45 +02:00
auto now = time_since_boot();
Scheduler: Move thread unblocking out of a lambda to help make things more readable We also use a switch to explicitly make sure we handle all cases properly.
2019-07-18 14:10:28 +02:00
Kernel: Do timekeeping manually instead of asking the RTC all the time. This introduces a tiny amount of timer drift which I will have to fix somehow eventually, but it's a huge improvement in timing consistency as we no longer suddenly jump from e.g 10:45:49.123 to 10:45:50.000.
2019-03-25 02:06:57 +01:00
auto now_sec = now.tv_sec;
auto now_usec = now.tv_usec;
Add support for socket send/receive timeouts. Only the receive timeout is hooked up yet. You can change the timeout by calling setsockopt(..., SOL_SOCKET, SO_RCVTIMEO, ...). Use this mechanism to make /bin/ping report timeouts.
2019-03-13 13:13:23 +01:00
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
ScopedSpinLock lock(g_scheduler_lock);
Kernel: Introduce threads, and refactor everything in support of it. The scheduler now operates on threads, rather than on processes. Each process has a main thread, and can have any number of additional threads. The process exits when the main thread exits. This patch doesn't actually spawn any additional threads, it merely does all the plumbing needed to make it possible. :^)
2019-03-23 22:03:17 +01:00
// Check and unblock threads whose wait conditions have been met.
Move runnable/non-runnable list control entirely over to Scheduler This way, we can change how the scheduler works without having to change Thread too.
2019-07-19 17:21:13 +02:00
Scheduler::for_each_nonrunnable([&](Thread& thread) {
Scheduler: Move thread unblocking out of a lambda to help make things more readable We also use a switch to explicitly make sure we handle all cases properly.
2019-07-18 14:10:28 +02:00
thread.consider_unblock(now_sec, now_usec);
Kernel: Introduce threads, and refactor everything in support of it. The scheduler now operates on threads, rather than on processes. Each process has a main thread, and can have any number of additional threads. The process exits when the main thread exits. This patch doesn't actually spawn any additional threads, it merely does all the plumbing needed to make it possible. :^)
2019-03-23 22:03:17 +01:00
return IterationDecision::Continue;
});
Kernel: Run clang-format on everything.
2019-06-07 11:43:58 +02:00
Process::for_each([&](Process& process) {
Kernel: Introduce threads, and refactor everything in support of it. The scheduler now operates on threads, rather than on processes. Each process has a main thread, and can have any number of additional threads. The process exits when the main thread exits. This patch doesn't actually spawn any additional threads, it merely does all the plumbing needed to make it possible. :^)
2019-03-23 22:03:17 +01:00
if (process.is_dead()) {
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
if (current_thread->process().pid() != process.pid() && (!process.ppid() || !Process::from_pid(process.ppid()))) {
Let reap() communicate the dead process's exit status to the caller. This way the scheduler doesn't need to plumb the exit status into the waiter. We still plumb the waitee pid though, I don't love it but it can be fixed.
2018-11-28 22:01:24 +01:00
auto name = process.name();
auto pid = process.pid();
auto exit_status = Process::reap(process);
Kernel: Boot all APS all the way into their own idle loop
2020-06-28 22:36:12 -06:00
dbg() << "Scheduler[" << Processor::current().id() << "]: Reaped unparented process " << name << "(" << pid << "), exit status: " << exit_status.si_status;
Let reap() communicate the dead process's exit status to the caller. This way the scheduler doesn't need to plumb the exit status into the waiter. We still plumb the waitee pid though, I don't love it but it can be fixed.
2018-11-28 22:01:24 +01:00
}
Kernel: Implement the alarm() syscall.
2019-06-07 11:30:07 +02:00
return IterationDecision::Continue;
}
if (process.m_alarm_deadline && g_uptime > process.m_alarm_deadline) {
process.m_alarm_deadline = 0;
process.send_signal(SIGALRM, nullptr);
Get rid of the undertaker and have waitpid() be the reaper. For dead orphans, the scheduler calls reap().
2018-11-07 23:59:49 +01:00
}
Kernel: Implement the alarm() syscall.
2019-06-07 11:30:07 +02:00
return IterationDecision::Continue;
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
});
// Dispatch any pending signals.
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
Thread::for_each_living([&](Thread& thread) -> IterationDecision {
Kernel: Introduce threads, and refactor everything in support of it. The scheduler now operates on threads, rather than on processes. Each process has a main thread, and can have any number of additional threads. The process exits when the main thread exits. This patch doesn't actually spawn any additional threads, it merely does all the plumbing needed to make it possible. :^)
2019-03-23 22:03:17 +01:00
if (!thread.has_unmasked_pending_signals())
Thread: Normalize all for_each constructs to use IterationDecision This way a caller can abort the for_each early if they want.
2019-07-19 12:16:00 +02:00
return IterationDecision::Continue;
Kernel: More signal handling improvements. Finally fixed the weird flaky crashing when resizing Terminal windows. It was because we were dispatching a signal to "current" from the scheduler. Yet another thing I dislike about even having a "current" process while we're in the scheduler. Not sure yet how to fix this. Let the signal handler's kernel stack be a kmalloc() allocation for now. Once we can do allocation of consecutive physical pages in the supervisor memory region, we can use that for all types of kernel stacks.
2019-03-05 12:50:55 +01:00
// FIXME: It would be nice if the Scheduler didn't have to worry about who is "current"
// For now, avoid dispatching signals to "current" and do it in a scheduling pass
// while some other process is interrupted. Otherwise a mess will be made.
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
if (&thread == current_thread)
Thread: Normalize all for_each constructs to use IterationDecision This way a caller can abort the for_each early if they want.
2019-07-19 12:16:00 +02:00
return IterationDecision::Continue;
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
// We know how to interrupt blocked processes, but if they are just executing
Kernel: Dispatch pending signals when returning from a syscall It was quite easy to put the system into a heavy churn state by doing e.g "cat /dev/zero". It was then basically impossible to kill the "cat" process, even with "kill -9", since signals are only delivered in two conditions: a) The target thread is blocked in the kernel b) The target thread is running in userspace However, since "cat /dev/zero" command spends most of its time actively running in the kernel, not blocked, the signal dispatch code just kept postponing actually handling the signal indefinitely. To fix this, we now check before returning from a syscall if there are any pending unmasked signals, and if so, we take a dramatic pause by blocking the current thread, knowing it will immediately be unblocked by signal dispatch anyway. :^)
2020-01-12 15:04:33 +01:00
// at some random point in the kernel, let them continue.
// Before returning to userspace from a syscall, we will block a thread if it has any
// pending unmasked signals, allowing it to be dispatched then.
Kernel: Introduce threads, and refactor everything in support of it. The scheduler now operates on threads, rather than on processes. Each process has a main thread, and can have any number of additional threads. The process exits when the main thread exits. This patch doesn't actually spawn any additional threads, it merely does all the plumbing needed to make it possible. :^)
2019-03-23 22:03:17 +01:00
if (thread.in_kernel() && !thread.is_blocked() && !thread.is_stopped())
Thread: Normalize all for_each constructs to use IterationDecision This way a caller can abort the for_each early if they want.
2019-07-19 12:16:00 +02:00
return IterationDecision::Continue;
Fix bug where a signal-interrupted waitpid() wouldn't return EINTR.
2018-11-28 23:30:06 +01:00
// NOTE: dispatch_one_pending_signal() may unblock the process.
Kernel: Introduce threads, and refactor everything in support of it. The scheduler now operates on threads, rather than on processes. Each process has a main thread, and can have any number of additional threads. The process exits when the main thread exits. This patch doesn't actually spawn any additional threads, it merely does all the plumbing needed to make it possible. :^)
2019-03-23 22:03:17 +01:00
bool was_blocked = thread.is_blocked();
if (thread.dispatch_one_pending_signal() == ShouldUnblockThread::No)
Thread: Normalize all for_each constructs to use IterationDecision This way a caller can abort the for_each early if they want.
2019-07-19 12:16:00 +02:00
return IterationDecision::Continue;
Fix bug where a signal-interrupted waitpid() wouldn't return EINTR.
2018-11-28 23:30:06 +01:00
if (was_blocked) {
Kernel: Silence some debug spam in Scheduler
2020-06-22 21:18:16 +02:00
#ifdef SCHEDULER_DEBUG
Kernel: Boot all APS all the way into their own idle loop
2020-06-28 22:36:12 -06:00
dbg() << "Scheduler[" << Processor::current().id() << "]:Unblock " << thread << " due to signal";
Kernel: Silence some debug spam in Scheduler
2020-06-22 21:18:16 +02:00
#endif
Kernel: Change m_blockers to m_blocker. Because of the way signals now work there should not be more than one blocker per thread. This changes the blocker and thread class to reflect that.
2019-09-09 15:58:42 +12:00
ASSERT(thread.m_blocker != nullptr);
thread.m_blocker->set_interrupted_by_signal();
Kernel: Introduce threads, and refactor everything in support of it. The scheduler now operates on threads, rather than on processes. Each process has a main thread, and can have any number of additional threads. The process exits when the main thread exits. This patch doesn't actually spawn any additional threads, it merely does all the plumbing needed to make it possible. :^)
2019-03-23 22:03:17 +01:00
thread.unblock();
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
}
Thread: Normalize all for_each constructs to use IterationDecision This way a caller can abort the for_each early if they want.
2019-07-19 12:16:00 +02:00
return IterationDecision::Continue;
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
});
Kernel: Split SCHEDULER_DEBUG into a new SCHEDULER_RUNNABLE_DEBUG And use dbgprintf() consistently on a few of the pieces of logging here. This is useful when trying to track thread switching when you don't really care about what it's switching _to_.
2019-07-17 14:17:49 +02:00
#ifdef SCHEDULER_RUNNABLE_DEBUG
Scheduler: Use dbg() instead of dbgprintf()
2020-02-24 15:15:12 +02:00
dbg() << "Non-runnables:";
Scheduler: Fix bitrotted SCHEDULER_RUNNABLE_DEBUG code The runnable lists have moved from Thread to Scheduler.
2019-08-01 20:00:45 +02:00
Scheduler::for_each_nonrunnable([](Thread& thread) -> IterationDecision {
Kernel: Various context switch fixes These changes solve a number of problems with the software context swithcing: * The scheduler lock really should be held throughout context switches * Transitioning from the initial (idle) thread to another needs to hold the scheduler lock * Transitioning from a dying thread to another also needs to hold the scheduler lock * Dying threads cannot necessarily be finalized if they haven't switched out of it yet, so flag them as active while a processor is running it (the Running state may be switched to Dying while it still is actually running)
2020-07-05 14:32:07 -06:00
if (thread.state() == Thread::Queued)
dbg() << " " << String::format("%-12s", thread.state_string()) << " " << thread << " @ " << String::format("%w", thread.tss().cs) << ":" << String::format("%x", thread.tss().eip) << " Reason: " << (thread.wait_reason() ? thread.wait_reason() : "none");
else if (thread.state() == Thread::Dying)
dbg() << " " << String::format("%-12s", thread.state_string()) << " " << thread << " @ " << String::format("%w", thread.tss().cs) << ":" << String::format("%x", thread.tss().eip) << " Finalizable: " << thread.is_finalizable();
Scheduler: Remove some raw use of the runnable lists
2019-07-19 12:18:40 +02:00
return IterationDecision::Continue;
});
Kernel: Add support for recv() with MSG_DONTWAIT. Passing this flag to recv() temporarily puts the file descriptor into non-blocking mode. Also implement LocalSocket::recv() as a simple forwarding to read().
2019-05-20 03:44:45 +02:00
Scheduler: Use dbg() instead of dbgprintf()
2020-02-24 15:15:12 +02:00
dbg() << "Runnables:";
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. :^)
2019-12-30 18:46:17 +01:00
Scheduler::for_each_runnable([](Thread& thread) -> IterationDecision {
Kernel: Simplify some dbg() logging We don't have to log the process name/PID/TID, dbg() automatically adds that as a prefix to every line. Also we don't have to do .characters() on Strings passed to dbg() :^)
2020-02-29 12:51:44 +01:00
dbg() << " " << String::format("%3u", thread.effective_priority()) << "/" << String::format("%2u", thread.priority()) << " " << String::format("%-12s", thread.state_string()) << " " << thread << " @ " << String::format("%w", thread.tss().cs) << ":" << String::format("%x", thread.tss().eip);
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. :^)
2019-12-30 18:46:17 +01:00
return IterationDecision::Continue;
});
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
#endif
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. :^)
2019-12-30 18:46:17 +01:00
Vector<Thread*, 128> sorted_runnables;
for_each_runnable([&sorted_runnables](auto& thread) {
Kernel: Boot all APS all the way into their own idle loop
2020-06-28 22:36:12 -06:00
if ((thread.affinity() & (1u << Processor::current().id())) != 0)
sorted_runnables.append(&thread);
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. :^)
2019-12-30 18:46:17 +01:00
return IterationDecision::Continue;
});
AK: Make quick_sort() a little more ergonomic Now it actually defaults to "a < b" comparison, instead of forcing you to provide a trivial less-than comparator. Also you can pass in any collection type that has .begin() and .end() and we'll sort it for you.
2020-03-03 16:01:37 +01:00
quick_sort(sorted_runnables, [](auto& a, auto& b) { return a->effective_priority() >= b->effective_priority(); });
Kernel: Make sure we never put the colonel thread in the runnable list. This would cause it to get scheduled unnecessarily.
2019-05-18 20:24:55 +02:00
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. :^)
2019-12-30 18:46:17 +01:00
Thread* thread_to_schedule = nullptr;
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
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. :^)
2019-12-30 18:46:17 +01:00
for (auto* thread : sorted_runnables) {
if (thread->process().is_being_inspected())
continue;
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
Kernel: Allow process with multiple threads to call exec and exit This allows a process wich has more than 1 thread to call exec, even from a thread. This kills all the other threads, but it won't wait for them to finish, just makes sure that they are not in a running/runable state. In the case where a thread does exec, the new program PID will be the thread TID, to keep the PID == TID in the new process. This introduces a new function inside the Process class, kill_threads_except_self which is called on exit() too (exit with multiple threads wasn't properly working either). Inside the Lock class, there is the need for a new function, clear_waiters, which removes all the waiters from the Process::big_lock. This is needed since after a exit/exec, there should be no other threads waiting for this lock, the threads should be simply killed. Only queued threads should wait for this lock at this point, since blocked threads are handled in set_should_die.
2020-02-18 14:28:28 +02:00
if (thread->process().exec_tid() && thread->process().exec_tid() != thread->tid())
continue;
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. :^)
2019-12-30 18:46:17 +01:00
ASSERT(thread->state() == Thread::Runnable || thread->state() == Thread::Running);
if (!thread_to_schedule) {
thread->m_extra_priority = 0;
thread_to_schedule = thread;
} else {
thread->m_extra_priority++;
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
}
}
Kernel: Separate runnable thread queues by priority This patch introduces three separate thread queues, one for each thread priority available to userspace (Low, Normal and High.) Each queue operates in a round-robin fashion, but we now always prefer to schedule the highest priority thread that currently wants to run. There are tons of tweaks and improvements that we can and should make to this mechanism, but I think this is a step in the right direction. This makes WindowServer significantly more responsive while one of its clients is burning CPU. :^)
2019-12-27 00:46:38 +01:00
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. :^)
2019-12-30 18:46:17 +01:00
if (!thread_to_schedule)
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
thread_to_schedule = Processor::current().idle_thread();
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. :^)
2019-12-30 18:46:17 +01:00
#ifdef SCHEDULER_DEBUG
Kernel: Boot all APS all the way into their own idle loop
2020-06-28 22:36:12 -06:00
dbg() << "Scheduler[" << Processor::current().id() << "]: Switch to " << *thread_to_schedule << " @ " << String::format("%04x:%08x", thread_to_schedule->tss().cs, thread_to_schedule->tss().eip);
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. :^)
2019-12-30 18:46:17 +01:00
#endif
Kernel: Various context switch fixes These changes solve a number of problems with the software context swithcing: * The scheduler lock really should be held throughout context switches * Transitioning from the initial (idle) thread to another needs to hold the scheduler lock * Transitioning from a dying thread to another also needs to hold the scheduler lock * Dying threads cannot necessarily be finalized if they haven't switched out of it yet, so flag them as active while a processor is running it (the Running state may be switched to Dying while it still is actually running)
2020-07-05 14:32:07 -06:00
return context_switch(thread_to_schedule);
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
}
Kernel: Implement software context switching and Processor structure Moving certain globals into a new Processor structure for each CPU allows us to eventually run an instance of the scheduler on each CPU.
2020-06-27 13:42:28 -06:00
bool Scheduler::yield()
{
Kernel: Fix signal delivery When delivering urgent signals to the current thread we need to check if we should be unblocked, and if not we need to yield to another process. We also need to make sure that we suppress context switches during Process::exec() so that we don't clobber the registers that it sets up (eip mainly) by a context switch. To be able to do that we add the concept of a critical section, which are similar to Process::m_in_irq but different in that they can be requested at any time. Calls to Scheduler::yield and Scheduler::donate_to will return instantly without triggering a context switch, but the processor will then asynchronously trigger a context switch once the critical section is left.
2020-07-03 05:19:50 -06:00
InterruptDisabler disabler;
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
auto& proc = Processor::current();
auto current_thread = Thread::current();
#ifdef SCHEDULER_DEBUG
Kernel: Fix signal delivery When delivering urgent signals to the current thread we need to check if we should be unblocked, and if not we need to yield to another process. We also need to make sure that we suppress context switches during Process::exec() so that we don't clobber the registers that it sets up (eip mainly) by a context switch. To be able to do that we add the concept of a critical section, which are similar to Process::m_in_irq but different in that they can be requested at any time. Calls to Scheduler::yield and Scheduler::donate_to will return instantly without triggering a context switch, but the processor will then asynchronously trigger a context switch once the critical section is left.
2020-07-03 05:19:50 -06:00
dbg() << "Scheduler[" << proc.id() << "]: yielding thread " << *current_thread << " in_irq: " << proc.in_irq();
Kernel: Implement software context switching and Processor structure Moving certain globals into a new Processor structure for each CPU allows us to eventually run an instance of the scheduler on each CPU.
2020-06-27 13:42:28 -06:00
#endif
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
ASSERT(current_thread != nullptr);
Kernel: Fix signal delivery When delivering urgent signals to the current thread we need to check if we should be unblocked, and if not we need to yield to another process. We also need to make sure that we suppress context switches during Process::exec() so that we don't clobber the registers that it sets up (eip mainly) by a context switch. To be able to do that we add the concept of a critical section, which are similar to Process::m_in_irq but different in that they can be requested at any time. Calls to Scheduler::yield and Scheduler::donate_to will return instantly without triggering a context switch, but the processor will then asynchronously trigger a context switch once the critical section is left.
2020-07-03 05:19:50 -06:00
if (proc.in_irq() || proc.in_critical()) {
// If we're handling an IRQ we can't switch context, or we're in
// a critical section where we don't want to switch contexts, then
// delay until exiting the trap or critical section
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
proc.invoke_scheduler_async();
Kernel: Fix signal delivery When delivering urgent signals to the current thread we need to check if we should be unblocked, and if not we need to yield to another process. We also need to make sure that we suppress context switches during Process::exec() so that we don't clobber the registers that it sets up (eip mainly) by a context switch. To be able to do that we add the concept of a critical section, which are similar to Process::m_in_irq but different in that they can be requested at any time. Calls to Scheduler::yield and Scheduler::donate_to will return instantly without triggering a context switch, but the processor will then asynchronously trigger a context switch once the critical section is left.
2020-07-03 05:19:50 -06:00
return false;
Kernel: Implement software context switching and Processor structure Moving certain globals into a new Processor structure for each CPU allows us to eventually run an instance of the scheduler on each CPU.
2020-06-27 13:42:28 -06:00
} else if (!Scheduler::pick_next())
return false;
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
#ifdef SCHEDULER_DEBUG
Kernel: Fix signal delivery When delivering urgent signals to the current thread we need to check if we should be unblocked, and if not we need to yield to another process. We also need to make sure that we suppress context switches during Process::exec() so that we don't clobber the registers that it sets up (eip mainly) by a context switch. To be able to do that we add the concept of a critical section, which are similar to Process::m_in_irq but different in that they can be requested at any time. Calls to Scheduler::yield and Scheduler::donate_to will return instantly without triggering a context switch, but the processor will then asynchronously trigger a context switch once the critical section is left.
2020-07-03 05:19:50 -06:00
dbg() << "Scheduler[" << proc.id() << "]: yield returns to thread " << *current_thread << " in_irq: " << proc.in_irq();
Kernel: Implement software context switching and Processor structure Moving certain globals into a new Processor structure for each CPU allows us to eventually run an instance of the scheduler on each CPU.
2020-06-27 13:42:28 -06:00
#endif
return true;
}
Kernel: Introduce threads, and refactor everything in support of it. The scheduler now operates on threads, rather than on processes. Each process has a main thread, and can have any number of additional threads. The process exits when the main thread exits. This patch doesn't actually spawn any additional threads, it merely does all the plumbing needed to make it possible. :^)
2019-03-23 22:03:17 +01:00
bool Scheduler::donate_to(Thread* beneficiary, const char* reason)
Kernel: When a lock is busy, donate remaining process ticks to lock holder. Since we know who's holding the lock, and we're gonna have to yield anyway, we can just ask the scheduler to donate any remaining ticks to that process.
2019-02-07 11:12:23 +01:00
{
Kernel: Various context switch fixes These changes solve a number of problems with the software context swithcing: * The scheduler lock really should be held throughout context switches * Transitioning from the initial (idle) thread to another needs to hold the scheduler lock * Transitioning from a dying thread to another also needs to hold the scheduler lock * Dying threads cannot necessarily be finalized if they haven't switched out of it yet, so flag them as active while a processor is running it (the Running state may be switched to Dying while it still is actually running)
2020-07-05 14:32:07 -06:00
ScopedSpinLock lock(g_scheduler_lock);
Kernel: Fix signal delivery When delivering urgent signals to the current thread we need to check if we should be unblocked, and if not we need to yield to another process. We also need to make sure that we suppress context switches during Process::exec() so that we don't clobber the registers that it sets up (eip mainly) by a context switch. To be able to do that we add the concept of a critical section, which are similar to Process::m_in_irq but different in that they can be requested at any time. Calls to Scheduler::yield and Scheduler::donate_to will return instantly without triggering a context switch, but the processor will then asynchronously trigger a context switch once the critical section is left.
2020-07-03 05:19:50 -06:00
auto& proc = Processor::current();
ASSERT(!proc.in_irq());
Kernel: Scheduler donations need to verify that the beneficiary is valid. Add a Thread::is_thread(void*) helper that we can use to check that the incoming donation beneficiary is a valid thread. The O(n) here is a bit sad and we should eventually rethink the process/thread table data structures.
2019-04-17 12:41:51 +02:00
if (!Thread::is_thread(beneficiary))
return false;
Kernel: Fix signal delivery When delivering urgent signals to the current thread we need to check if we should be unblocked, and if not we need to yield to another process. We also need to make sure that we suppress context switches during Process::exec() so that we don't clobber the registers that it sets up (eip mainly) by a context switch. To be able to do that we add the concept of a critical section, which are similar to Process::m_in_irq but different in that they can be requested at any time. Calls to Scheduler::yield and Scheduler::donate_to will return instantly without triggering a context switch, but the processor will then asynchronously trigger a context switch once the critical section is left.
2020-07-03 05:19:50 -06:00
if (proc.in_critical()) {
proc.invoke_scheduler_async();
return false;
}
Kernel: When a lock is busy, donate remaining process ticks to lock holder. Since we know who's holding the lock, and we're gonna have to yield anyway, we can just ask the scheduler to donate any remaining ticks to that process.
2019-02-07 11:12:23 +01:00
(void)reason;
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
unsigned ticks_left = Thread::current()->ticks_left();
Kernel: Scheduler donations need to verify that the beneficiary is valid. Add a Thread::is_thread(void*) helper that we can use to check that the incoming donation beneficiary is a valid thread. The O(n) here is a bit sad and we should eventually rethink the process/thread table data structures.
2019-04-17 12:41:51 +02:00
if (!beneficiary || beneficiary->state() != Thread::Runnable || ticks_left <= 1)
Kernel: Implement software context switching and Processor structure Moving certain globals into a new Processor structure for each CPU allows us to eventually run an instance of the scheduler on each CPU.
2020-06-27 13:42:28 -06:00
return Scheduler::yield();
Kernel: When a lock is busy, donate remaining process ticks to lock holder. Since we know who's holding the lock, and we're gonna have to yield anyway, we can just ask the scheduler to donate any remaining ticks to that process.
2019-02-07 11:12:23 +01:00
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. :^)
2019-12-30 18:46:17 +01:00
unsigned ticks_to_donate = min(ticks_left - 1, time_slice_for(*beneficiary));
Kernel: When a lock is busy, donate remaining process ticks to lock holder. Since we know who's holding the lock, and we're gonna have to yield anyway, we can just ask the scheduler to donate any remaining ticks to that process.
2019-02-07 11:12:23 +01:00
#ifdef SCHEDULER_DEBUG
Kernel: Fix signal delivery When delivering urgent signals to the current thread we need to check if we should be unblocked, and if not we need to yield to another process. We also need to make sure that we suppress context switches during Process::exec() so that we don't clobber the registers that it sets up (eip mainly) by a context switch. To be able to do that we add the concept of a critical section, which are similar to Process::m_in_irq but different in that they can be requested at any time. Calls to Scheduler::yield and Scheduler::donate_to will return instantly without triggering a context switch, but the processor will then asynchronously trigger a context switch once the critical section is left.
2020-07-03 05:19:50 -06:00
dbg() << "Scheduler[" << proc.id() << "]: Donating " << ticks_to_donate << " ticks to " << *beneficiary << ", reason=" << reason;
Kernel: When a lock is busy, donate remaining process ticks to lock holder. Since we know who's holding the lock, and we're gonna have to yield anyway, we can just ask the scheduler to donate any remaining ticks to that process.
2019-02-07 11:12:23 +01:00
#endif
beneficiary->set_ticks_left(ticks_to_donate);
Kernel: Various context switch fixes These changes solve a number of problems with the software context swithcing: * The scheduler lock really should be held throughout context switches * Transitioning from the initial (idle) thread to another needs to hold the scheduler lock * Transitioning from a dying thread to another also needs to hold the scheduler lock * Dying threads cannot necessarily be finalized if they haven't switched out of it yet, so flag them as active while a processor is running it (the Running state may be switched to Dying while it still is actually running)
2020-07-05 14:32:07 -06:00
Scheduler::context_switch(beneficiary);
Kernel: Scheduler donations need to verify that the beneficiary is valid. Add a Thread::is_thread(void*) helper that we can use to check that the incoming donation beneficiary is a valid thread. The O(n) here is a bit sad and we should eventually rethink the process/thread table data structures.
2019-04-17 12:41:51 +02:00
return false;
Kernel: When a lock is busy, donate remaining process ticks to lock holder. Since we know who's holding the lock, and we're gonna have to yield anyway, we can just ask the scheduler to donate any remaining ticks to that process.
2019-02-07 11:12:23 +01:00
}
Kernel: Various context switch fixes These changes solve a number of problems with the software context swithcing: * The scheduler lock really should be held throughout context switches * Transitioning from the initial (idle) thread to another needs to hold the scheduler lock * Transitioning from a dying thread to another also needs to hold the scheduler lock * Dying threads cannot necessarily be finalized if they haven't switched out of it yet, so flag them as active while a processor is running it (the Running state may be switched to Dying while it still is actually running)
2020-07-05 14:32:07 -06:00
bool Scheduler::context_switch(Thread* thread)
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
{
Kernel: Various context switch fixes These changes solve a number of problems with the software context swithcing: * The scheduler lock really should be held throughout context switches * Transitioning from the initial (idle) thread to another needs to hold the scheduler lock * Transitioning from a dying thread to another also needs to hold the scheduler lock * Dying threads cannot necessarily be finalized if they haven't switched out of it yet, so flag them as active while a processor is running it (the Running state may be switched to Dying while it still is actually running)
2020-07-05 14:32:07 -06:00
thread->set_ticks_left(time_slice_for(*thread));
thread->did_schedule();
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
Kernel: Various context switch fixes These changes solve a number of problems with the software context swithcing: * The scheduler lock really should be held throughout context switches * Transitioning from the initial (idle) thread to another needs to hold the scheduler lock * Transitioning from a dying thread to another also needs to hold the scheduler lock * Dying threads cannot necessarily be finalized if they haven't switched out of it yet, so flag them as active while a processor is running it (the Running state may be switched to Dying while it still is actually running)
2020-07-05 14:32:07 -06:00
auto from_thread = Thread::current();
if (from_thread == thread)
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
return false;
Kernel: Various context switch fixes These changes solve a number of problems with the software context swithcing: * The scheduler lock really should be held throughout context switches * Transitioning from the initial (idle) thread to another needs to hold the scheduler lock * Transitioning from a dying thread to another also needs to hold the scheduler lock * Dying threads cannot necessarily be finalized if they haven't switched out of it yet, so flag them as active while a processor is running it (the Running state may be switched to Dying while it still is actually running)
2020-07-05 14:32:07 -06:00
if (from_thread) {
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
// If the last process hasn't blocked (still marked as running),
// mark it as runnable for the next round.
Kernel: Various context switch fixes These changes solve a number of problems with the software context swithcing: * The scheduler lock really should be held throughout context switches * Transitioning from the initial (idle) thread to another needs to hold the scheduler lock * Transitioning from a dying thread to another also needs to hold the scheduler lock * Dying threads cannot necessarily be finalized if they haven't switched out of it yet, so flag them as active while a processor is running it (the Running state may be switched to Dying while it still is actually running)
2020-07-05 14:32:07 -06:00
if (from_thread->state() == Thread::Running)
from_thread->set_state(Thread::Runnable);
Reduce number of passes in the scheduler by 2.
2018-11-07 22:24:20 +01:00
#ifdef LOG_EVERY_CONTEXT_SWITCH
Kernel: Various context switch fixes These changes solve a number of problems with the software context swithcing: * The scheduler lock really should be held throughout context switches * Transitioning from the initial (idle) thread to another needs to hold the scheduler lock * Transitioning from a dying thread to another also needs to hold the scheduler lock * Dying threads cannot necessarily be finalized if they haven't switched out of it yet, so flag them as active while a processor is running it (the Running state may be switched to Dying while it still is actually running)
2020-07-05 14:32:07 -06:00
dbg() << "Scheduler[" << Processor::current().id() << "]: " << *from_thread << " -> " << *thread << " [" << thread->priority() << "] " << String::format("%w", thread->tss().cs) << ":" << String::format("%x", thread->tss().eip);
Reduce number of passes in the scheduler by 2.
2018-11-07 22:24:20 +01:00
#endif
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
}
Kernel: Fix signal delivery When delivering urgent signals to the current thread we need to check if we should be unblocked, and if not we need to yield to another process. We also need to make sure that we suppress context switches during Process::exec() so that we don't clobber the registers that it sets up (eip mainly) by a context switch. To be able to do that we add the concept of a critical section, which are similar to Process::m_in_irq but different in that they can be requested at any time. Calls to Scheduler::yield and Scheduler::donate_to will return instantly without triggering a context switch, but the processor will then asynchronously trigger a context switch once the critical section is left.
2020-07-03 05:19:50 -06:00
auto& proc = Processor::current();
Kernel: Various context switch fixes These changes solve a number of problems with the software context swithcing: * The scheduler lock really should be held throughout context switches * Transitioning from the initial (idle) thread to another needs to hold the scheduler lock * Transitioning from a dying thread to another also needs to hold the scheduler lock * Dying threads cannot necessarily be finalized if they haven't switched out of it yet, so flag them as active while a processor is running it (the Running state may be switched to Dying while it still is actually running)
2020-07-05 14:32:07 -06:00
if (!thread->is_initialized()) {
proc.init_context(*thread, false);
thread->set_initialized(true);
Kernel: Support thread-local storage This patch adds support for TLS according to the x86 System V ABI. Each thread gets a thread-specific memory region, and the GS segment register always points _to a pointer_ to the thread-specific memory. In other words, to access thread-local variables, userspace programs start by dereferencing the pointer at [gs:0]. The Process keeps a master copy of the TLS segment that new threads should use, and when a new thread is created, they get a copy of it. It's basically whatever the PT_TLS program header in the ELF says.
2019-09-07 15:50:44 +02:00
}
Kernel: Various context switch fixes These changes solve a number of problems with the software context swithcing: * The scheduler lock really should be held throughout context switches * Transitioning from the initial (idle) thread to another needs to hold the scheduler lock * Transitioning from a dying thread to another also needs to hold the scheduler lock * Dying threads cannot necessarily be finalized if they haven't switched out of it yet, so flag them as active while a processor is running it (the Running state may be switched to Dying while it still is actually running)
2020-07-05 14:32:07 -06:00
thread->set_state(Thread::Running);
// Mark it as active because we are using this thread. This is similar
// to comparing it with Processor::current_thread, but when there are
// multiple processors there's no easy way to check whether the thread
// is actually still needed. This prevents accidental finalization when
// a thread is no longer in Running state, but running on another core.
thread->set_active(true);
proc.switch_context(from_thread, thread);
// NOTE: from_thread at this point reflects the thread we were
// switched from, and thread reflects Thread::current()
enter_current(*from_thread);
ASSERT(thread == Thread::current());
Kernel: Support thread-local storage This patch adds support for TLS according to the x86 System V ABI. Each thread gets a thread-specific memory region, and the GS segment register always points _to a pointer_ to the thread-specific memory. In other words, to access thread-local variables, userspace programs start by dereferencing the pointer at [gs:0]. The Process keeps a master copy of the TLS segment that new threads should use, and when a new thread is created, they get a copy of it. It's basically whatever the PT_TLS program header in the ELF says.
2019-09-07 15:50:44 +02:00
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
return true;
}
Kernel: Various context switch fixes These changes solve a number of problems with the software context swithcing: * The scheduler lock really should be held throughout context switches * Transitioning from the initial (idle) thread to another needs to hold the scheduler lock * Transitioning from a dying thread to another also needs to hold the scheduler lock * Dying threads cannot necessarily be finalized if they haven't switched out of it yet, so flag them as active while a processor is running it (the Running state may be switched to Dying while it still is actually running)
2020-07-05 14:32:07 -06:00
void Scheduler::enter_current(Thread& prev_thread)
{
ASSERT(g_scheduler_lock.is_locked());
prev_thread.set_active(false);
if (prev_thread.state() == Thread::Dying) {
// If the thread we switched from is marked as dying, then notify
// the finalizer. Note that as soon as we leave the scheduler lock
// the finalizer may free from_thread!
notify_finalizer();
}
}
Add a /bin/top program for process table monitoring. It automagically computes %CPU usage based on the number of times a process has been scheduled between samples. The colonel task is used as idle timer. This is pretty cool. :^)
2019-02-04 10:28:12 +01:00
Process* Scheduler::colonel()
{
return s_colonel_process;
}
Kernel: Implement software context switching and Processor structure Moving certain globals into a new Processor structure for each CPU allows us to eventually run an instance of the scheduler on each CPU.
2020-06-27 13:42:28 -06:00
void Scheduler::initialize(u32 cpu)
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
{
Kernel: Block initializing the Scheduler on the APs until the BSP initialized global data
2020-06-28 16:05:52 -06:00
static Atomic<u32> s_bsp_is_initialized;
Kernel: Implement software context switching and Processor structure Moving certain globals into a new Processor structure for each CPU allows us to eventually run an instance of the scheduler on each CPU.
2020-06-27 13:42:28 -06:00
ASSERT(&Processor::current() != nullptr); // sanity check
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
Thread* idle_thread = nullptr;
Kernel: Implement software context switching and Processor structure Moving certain globals into a new Processor structure for each CPU allows us to eventually run an instance of the scheduler on each CPU.
2020-06-27 13:42:28 -06:00
if (cpu == 0) {
Kernel: Block initializing the Scheduler on the APs until the BSP initialized global data
2020-06-28 16:05:52 -06:00
ASSERT(s_bsp_is_initialized.load(AK::MemoryOrder::memory_order_consume) == 0);
g_scheduler_data = new SchedulerData;
g_finalizer_wait_queue = new WaitQueue;
Kernel: Implement software context switching and Processor structure Moving certain globals into a new Processor structure for each CPU allows us to eventually run an instance of the scheduler on each CPU.
2020-06-27 13:42:28 -06:00
g_finalizer_has_work.store(false, AK::MemoryOrder::memory_order_release);
Kernel: Boot all APS all the way into their own idle loop
2020-06-28 22:36:12 -06:00
s_colonel_process = Process::create_kernel_process(idle_thread, "colonel", idle_loop, 1 << cpu);
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
ASSERT(s_colonel_process);
ASSERT(idle_thread);
idle_thread->set_priority(THREAD_PRIORITY_MIN);
idle_thread->set_name(String::format("idle thread #%u", cpu));
} else {
Kernel: Block initializing the Scheduler on the APs until the BSP initialized global data
2020-06-28 16:05:52 -06:00
// We need to make sure the BSP initialized the global data first
if (s_bsp_is_initialized.load(AK::MemoryOrder::memory_order_consume) == 0) {
Kernel: Boot all APS all the way into their own idle loop
2020-06-28 22:36:12 -06:00
#ifdef SCHEDULER_DEBUG
dbg() << "Scheduler[" << cpu << "]: waiting for BSP to initialize...";
#endif
Kernel: Block initializing the Scheduler on the APs until the BSP initialized global data
2020-06-28 16:05:52 -06:00
while (s_bsp_is_initialized.load(AK::MemoryOrder::memory_order_consume) == 0) {
}
Kernel: Boot all APS all the way into their own idle loop
2020-06-28 22:36:12 -06:00
#ifdef SCHEDULER_DEBUG
dbg() << "Scheduler[" << cpu << "]: initializing now";
#endif
Kernel: Block initializing the Scheduler on the APs until the BSP initialized global data
2020-06-28 16:05:52 -06:00
}
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
ASSERT(s_colonel_process);
Kernel: Boot all APS all the way into their own idle loop
2020-06-28 22:36:12 -06:00
idle_thread = s_colonel_process->create_kernel_thread(idle_loop, THREAD_PRIORITY_MIN, String::format("idle thread #%u", cpu), 1 << cpu, false);
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
ASSERT(idle_thread);
Kernel: Implement software context switching and Processor structure Moving certain globals into a new Processor structure for each CPU allows us to eventually run an instance of the scheduler on each CPU.
2020-06-27 13:42:28 -06:00
}
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
Processor::current().set_idle_thread(*idle_thread);
Kernel: Boot all APS all the way into their own idle loop
2020-06-28 22:36:12 -06:00
Processor::current().set_current_thread(*idle_thread);
Kernel: Block initializing the Scheduler on the APs until the BSP initialized global data
2020-06-28 16:05:52 -06:00
if (cpu == 0)
s_bsp_is_initialized.store(1, AK::MemoryOrder::memory_order_release);
Move the scheduler code to its own class. This is very mechanical.
2018-11-07 22:15:02 +01:00
}
Move timer tick handling into Scheduler.
2018-11-08 00:24:59 +01:00
Kernel: Use a const reference to RegisterState in IRQ handling
2020-03-09 16:24:29 +02:00
void Scheduler::timer_tick(const RegisterState& regs)
Move timer tick handling into Scheduler.
2018-11-08 00:24:59 +01:00
{
Kernel: Implement software context switching and Processor structure Moving certain globals into a new Processor structure for each CPU allows us to eventually run an instance of the scheduler on each CPU.
2020-06-27 13:42:28 -06:00
ASSERT_INTERRUPTS_DISABLED();
ASSERT(Processor::current().in_irq());
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
auto current_thread = Processor::current().current_thread();
if (!current_thread)
Move timer tick handling into Scheduler.
2018-11-08 00:24:59 +01:00
return;
Kernel: Remove system.h and make the uptime global a qword.
2019-04-14 01:29:14 +02:00
++g_uptime;
Move timer tick handling into Scheduler.
2018-11-08 00:24:59 +01:00
Kernel: Add TimeManagement::now_as_timeval() Hide the implementation of time-of-day computation in TimeManagement.
2020-05-16 11:33:24 +02:00
g_timeofday = TimeManagement::now_as_timeval();
Kernel+LibC: Publish a "kernel info page" and use it for gettimeofday() This patch adds a single "kernel info page" that is mappable read-only by any process and contains the current time of day. This is then used to implement a version of gettimeofday() that doesn't have to make a syscall. To protect against race condition issues, the info page also has a serial number which is incremented whenever the kernel updates the contents of the page. Make sure to verify that the serial number is the same before and after reading the information you want from the page.
2019-12-15 21:29:26 +01:00
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
if (current_thread->process().is_profiling()) {
Kernel: Disable SMAP protection while capturing profile samples
2020-01-12 02:02:29 +01:00
SmapDisabler disabler;
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
auto backtrace = current_thread->raw_backtrace(regs.ebp, regs.eip);
Kernel: Implement a simple process time profiler The kernel now supports basic profiling of all the threads in a process by calling profiling_enable(pid_t). You finish the profiling by calling profiling_disable(pid_t). This all works by recording thread stacks when the timer interrupt fires and the current thread is in a process being profiled. Note that symbolication is deferred until profiling_disable() to avoid adding more noise than necessary to the profile. A simple "/bin/profile" command is included here that can be used to start/stop profiling like so: $ profile 10 on ... wait ... $ profile 10 off After a profile has been recorded, it can be fetched in /proc/profile There are various limits (or "bugs") on this mechanism at the moment: - Only one process can be profiled at a time. - We allocate 8MB for the samples, if you use more space, things will not work, and probably break a bit. - Things will probably fall apart if the profiled process dies during profiling, or while extracing /proc/profile
2019-12-11 20:36:56 +01:00
auto& sample = Profiling::next_sample_slot();
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
sample.pid = current_thread->process().pid();
sample.tid = current_thread->tid();
Kernel: Implement a simple process time profiler The kernel now supports basic profiling of all the threads in a process by calling profiling_enable(pid_t). You finish the profiling by calling profiling_disable(pid_t). This all works by recording thread stacks when the timer interrupt fires and the current thread is in a process being profiled. Note that symbolication is deferred until profiling_disable() to avoid adding more noise than necessary to the profile. A simple "/bin/profile" command is included here that can be used to start/stop profiling like so: $ profile 10 on ... wait ... $ profile 10 off After a profile has been recorded, it can be fetched in /proc/profile There are various limits (or "bugs") on this mechanism at the moment: - Only one process can be profiled at a time. - We allocate 8MB for the samples, if you use more space, things will not work, and probably break a bit. - Things will probably fall apart if the profiled process dies during profiling, or while extracing /proc/profile
2019-12-11 20:36:56 +01:00
sample.timestamp = g_uptime;
AK: Remove unnecessary casts to size_t, after Vector changes Now that Vector uses size_t, we can remove a whole bunch of redundant casts to size_t.
2020-03-01 12:35:09 +01:00
for (size_t i = 0; i < min(backtrace.size(), Profiling::max_stack_frame_count); ++i) {
Kernel: Implement a simple process time profiler The kernel now supports basic profiling of all the threads in a process by calling profiling_enable(pid_t). You finish the profiling by calling profiling_disable(pid_t). This all works by recording thread stacks when the timer interrupt fires and the current thread is in a process being profiled. Note that symbolication is deferred until profiling_disable() to avoid adding more noise than necessary to the profile. A simple "/bin/profile" command is included here that can be used to start/stop profiling like so: $ profile 10 on ... wait ... $ profile 10 off After a profile has been recorded, it can be fetched in /proc/profile There are various limits (or "bugs") on this mechanism at the moment: - Only one process can be profiled at a time. - We allocate 8MB for the samples, if you use more space, things will not work, and probably break a bit. - Things will probably fall apart if the profiled process dies during profiling, or while extracing /proc/profile
2019-12-11 20:36:56 +01:00
sample.frames[i] = backtrace[i];
}
}
Kernel: Add kernel-level timer queue (heavily based on @juliusf's work) PR #591 defines the rationale for kernel-level timers. They're most immediately useful for TCP retransmission, but will most likely see use in many other areas as well.
2019-12-27 11:58:28 +11:00
TimerQueue::the().fire();
Kernel: Turn Thread::current and Process::current into functions This allows us to query the current thread and process on a per processor basis
2020-06-28 15:34:31 -06:00
if (current_thread->tick())
Move timer tick handling into Scheduler.
2018-11-08 00:24:59 +01:00
return;
Kernel: Implement software context switching and Processor structure Moving certain globals into a new Processor structure for each CPU allows us to eventually run an instance of the scheduler on each CPU.
2020-06-27 13:42:28 -06:00
ASSERT_INTERRUPTS_DISABLED();
ASSERT(Processor::current().in_irq());
Processor::current().invoke_scheduler_async();
Move timer tick handling into Scheduler.
2018-11-08 00:24:59 +01:00
}
Kernel: Stop idling after handling an IRQ If we receive an IRQ while the idle task is running, prevent it from re-halting the CPU after the IRQ handler returns. Instead have the idle task yield to the scheduler, so we can see if the IRQ has unblocked something.
2019-09-14 19:44:22 +02:00
Kernel: Implement software context switching and Processor structure Moving certain globals into a new Processor structure for each CPU allows us to eventually run an instance of the scheduler on each CPU.
2020-06-27 13:42:28 -06:00
void Scheduler::invoke_async()
Kernel: Stop idling after handling an IRQ If we receive an IRQ while the idle task is running, prevent it from re-halting the CPU after the IRQ handler returns. Instead have the idle task yield to the scheduler, so we can see if the IRQ has unblocked something.
2019-09-14 19:44:22 +02:00
{
Kernel: Implement software context switching and Processor structure Moving certain globals into a new Processor structure for each CPU allows us to eventually run an instance of the scheduler on each CPU.
2020-06-27 13:42:28 -06:00
ASSERT_INTERRUPTS_DISABLED();
ASSERT(!Processor::current().in_irq());
pick_next();
Kernel: Stop idling after handling an IRQ If we receive an IRQ while the idle task is running, prevent it from re-halting the CPU after the IRQ handler returns. Instead have the idle task yield to the scheduler, so we can see if the IRQ has unblocked something.
2019-09-14 19:44:22 +02:00
}
Kernel: Various context switch fixes These changes solve a number of problems with the software context swithcing: * The scheduler lock really should be held throughout context switches * Transitioning from the initial (idle) thread to another needs to hold the scheduler lock * Transitioning from a dying thread to another also needs to hold the scheduler lock * Dying threads cannot necessarily be finalized if they haven't switched out of it yet, so flag them as active while a processor is running it (the Running state may be switched to Dying while it still is actually running)
2020-07-05 14:32:07 -06:00
void Scheduler::notify_finalizer()
{
if (g_finalizer_has_work.exchange(true, AK::MemoryOrder::memory_order_acq_rel) == false)
g_finalizer_wait_queue->wake_all();
}
Kernel: Stop idling after handling an IRQ If we receive an IRQ while the idle task is running, prevent it from re-halting the CPU after the IRQ handler returns. Instead have the idle task yield to the scheduler, so we can see if the IRQ has unblocked something.
2019-09-14 19:44:22 +02:00
void Scheduler::idle_loop()
{
Kernel: Boot all APS all the way into their own idle loop
2020-06-28 22:36:12 -06:00
dbg() << "Scheduler[" << Processor::current().id() << "]: idle loop running";
Kernel: Implement software context switching and Processor structure Moving certain globals into a new Processor structure for each CPU allows us to eventually run an instance of the scheduler on each CPU.
2020-06-27 13:42:28 -06:00
ASSERT(are_interrupts_enabled());
Kernel: Stop idling after handling an IRQ If we receive an IRQ while the idle task is running, prevent it from re-halting the CPU after the IRQ handler returns. Instead have the idle task yield to the scheduler, so we can see if the IRQ has unblocked something.
2019-09-14 19:44:22 +02:00
for (;;) {
asm("hlt");
Kernel: Implement software context switching and Processor structure Moving certain globals into a new Processor structure for each CPU allows us to eventually run an instance of the scheduler on each CPU.
2020-06-27 13:42:28 -06:00
yield();
Kernel: Stop idling after handling an IRQ If we receive an IRQ while the idle task is running, prevent it from re-halting the CPU after the IRQ handler returns. Instead have the idle task yield to the scheduler, so we can see if the IRQ has unblocked something.
2019-09-14 19:44:22 +02:00
}
}
Kernel: Move all code into the Kernel namespace
2020-02-16 01:27:42 +01:00
}
Reference in a new issue Copy permalink