beenull/ladybird
1
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2024-11-23 16:10:20 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
ladybird/Kernel/PerformanceEventBuffer.cpp

239 lines
8.7 KiB
C++
Raw Normal View History

Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
/*
Kernel+Profiler: Make profiling per-process and without core dumps This patch merges the profiling functionality in the kernel with the performance events mechanism. A profiler sample is now just another perf event, rather than a dedicated thing. Since perf events were already per-process, this now makes profiling per-process as well. Processes with perf events would already write out a perfcore.PID file to the current directory on death, but since we may want to profile a process and then let it continue running, recorded perf events can now be accessed at any time via /proc/PID/perf_events. This patch also adds information about process memory regions to the perfcore JSON format. This removes the need to supply a core dump to the Profiler app for symbolication, and so the "profiler coredump" mechanism is removed entirely. There's still a hard limit of 4MB worth of perf events per process, so this is by no means a perfect final design, but it's a nice step forward for both simplicity and stability. Fixes #4848 Fixes #4849
2021-01-11 08:52:18 +00:00
* Copyright (c) 2020-2021, Andreas Kling <kling@serenityos.org>
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 08:24:48 +00:00
* SPDX-License-Identifier: BSD-2-Clause
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
*/
#include <AK/JsonArraySerializer.h>
Kernel+ProfileViewer: Move symbolication to userspace for time profiles This makes the time profiles look like the memory profiles so we can use the userspace symbolication code in ProfileViewer.
2020-02-22 09:05:03 +00:00
#include <AK/JsonObject.h>
Kernel: Run clang-format on files Let's rip off the band-aid
2020-03-22 00:12:45 +00:00
#include <AK/JsonObjectSerializer.h>
Kernel: Move SMAP disabler RAII helper to its own file Added this in a new directory called Kernel/Arch/x86/ where stuff that applies to both i386 and x86_64 can live.
2021-02-25 16:25:34 +00:00
#include <Kernel/Arch/x86/SmapDisabler.h>
Kernel+Profiler: Capture metadata about all profiled processes The perfcore file format was previously limited to a single process since the pid/executable/regions data was top-level in the JSON. This patch moves the process-specific data into a top-level array named "processes" and we now add entries for each process that has been sampled during the profile run. This makes it possible to see samples from multiple threads when viewing a perfcore file with Profiler. This is extremely cool! :^)
2021-03-02 18:01:02 +00:00
#include <Kernel/FileSystem/Custody.h>
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
#include <Kernel/KBufferBuilder.h>
#include <Kernel/PerformanceEventBuffer.h>
Kernel+Profiler: Make profiling per-process and without core dumps This patch merges the profiling functionality in the kernel with the performance events mechanism. A profiler sample is now just another perf event, rather than a dedicated thing. Since perf events were already per-process, this now makes profiling per-process as well. Processes with perf events would already write out a perfcore.PID file to the current directory on death, but since we may want to profile a process and then let it continue running, recorded perf events can now be accessed at any time via /proc/PID/perf_events. This patch also adds information about process memory regions to the perfcore JSON format. This removes the need to supply a core dump to the Profiler app for symbolication, and so the "profiler coredump" mechanism is removed entirely. There's still a hard limit of 4MB worth of perf events per process, so this is by no means a perfect final design, but it's a nice step forward for both simplicity and stability. Fixes #4848 Fixes #4849
2021-01-11 08:52:18 +00:00
#include <Kernel/Process.h>
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
Kernel: Move all code into the Kernel namespace
2020-02-16 00:27:42 +00:00
namespace Kernel {
Kernel: Better handling of allocation failure in profiling If we can't allocate a PerformanceEventBuffer to store the profiling events, we now fail sys$profiling_enable() and sys$perf_event() with ENOMEM instead of carrying on with a broken buffer.
2021-03-02 15:55:54 +00:00
PerformanceEventBuffer::PerformanceEventBuffer(NonnullOwnPtr<KBuffer> buffer)
: m_buffer(move(buffer))
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
{
}
Kernel+Profiler: Improve profiling subsystem This turns the perfcore format into more a log than it was before, which lets us properly log process, thread and region creation/destruction. This also makes it unnecessary to dump the process' regions every time it is scheduled like we did before. Incidentally this also fixes 'profile -c' because we previously ended up incorrectly dumping the parent's region map into the profile data. Log-based mmap support enables profiling shared libraries which are loaded at runtime, e.g. via dlopen(). This enables profiling both the parent and child process for programs which use execve(). Previously we'd discard the profiling data for the old process. The Profiler tool has been updated to not treat thread IDs as process IDs anymore. This enables support for processes with more than one thread. Also, there's a new widget to filter which process should be displayed.
2021-04-25 21:42:36 +00:00
NEVER_INLINE KResult PerformanceEventBuffer::append(int type, FlatPtr arg1, FlatPtr arg2, const StringView& arg3)
Kernel: Prune uninteresting kernel frames from profiling samples Start capturing the sample stacks at the EIP/EBP of the pre-empted thread instead of capturing EBP in the sampling function itself.
2021-01-17 09:53:18 +00:00
{
FlatPtr ebp;
asm volatile("movl %%ebp, %%eax"
: "=a"(ebp));
auto current_thread = Thread::current();
Kernel+Profiler: Improve profiling subsystem This turns the perfcore format into more a log than it was before, which lets us properly log process, thread and region creation/destruction. This also makes it unnecessary to dump the process' regions every time it is scheduled like we did before. Incidentally this also fixes 'profile -c' because we previously ended up incorrectly dumping the parent's region map into the profile data. Log-based mmap support enables profiling shared libraries which are loaded at runtime, e.g. via dlopen(). This enables profiling both the parent and child process for programs which use execve(). Previously we'd discard the profiling data for the old process. The Profiler tool has been updated to not treat thread IDs as process IDs anymore. This enables support for processes with more than one thread. Also, there's a new widget to filter which process should be displayed.
2021-04-25 21:42:36 +00:00
return append_with_eip_and_ebp(current_thread->pid(), current_thread->tid(), 0, ebp, type, arg1, arg2, arg3);
Kernel: Prune uninteresting kernel frames from profiling samples Start capturing the sample stacks at the EIP/EBP of the pre-empted thread instead of capturing EBP in the sampling function itself.
2021-01-17 09:53:18 +00:00
}
Kernel: Move perf event backtrace capture out of Thread class There's no need for this to be generic and support running from an arbitrary thread context. Perf events are always generated from within the thread being profiled, so take advantage of that to simplify the code. Also use Vector capacity to avoid heap allocations.
2021-02-03 10:51:13 +00:00
static Vector<FlatPtr, PerformanceEvent::max_stack_frame_count> raw_backtrace(FlatPtr ebp, FlatPtr eip)
{
Vector<FlatPtr, PerformanceEvent::max_stack_frame_count> backtrace;
Kernel+Profiler: Improve profiling subsystem This turns the perfcore format into more a log than it was before, which lets us properly log process, thread and region creation/destruction. This also makes it unnecessary to dump the process' regions every time it is scheduled like we did before. Incidentally this also fixes 'profile -c' because we previously ended up incorrectly dumping the parent's region map into the profile data. Log-based mmap support enables profiling shared libraries which are loaded at runtime, e.g. via dlopen(). This enables profiling both the parent and child process for programs which use execve(). Previously we'd discard the profiling data for the old process. The Profiler tool has been updated to not treat thread IDs as process IDs anymore. This enables support for processes with more than one thread. Also, there's a new widget to filter which process should be displayed.
2021-04-25 21:42:36 +00:00
if (eip != 0)
backtrace.append(eip);
Kernel: Move perf event backtrace capture out of Thread class There's no need for this to be generic and support running from an arbitrary thread context. Perf events are always generated from within the thread being profiled, so take advantage of that to simplify the code. Also use Vector capacity to avoid heap allocations.
2021-02-03 10:51:13 +00:00
FlatPtr stack_ptr_copy;
FlatPtr stack_ptr = (FlatPtr)ebp;
// FIXME: Figure out how to remove this SmapDisabler without breaking profile stacks.
SmapDisabler disabler;
while (stack_ptr) {
void* fault_at;
if (!safe_memcpy(&stack_ptr_copy, (void*)stack_ptr, sizeof(FlatPtr), fault_at))
break;
FlatPtr retaddr;
if (!safe_memcpy(&retaddr, (void*)(stack_ptr + sizeof(FlatPtr)), sizeof(FlatPtr), fault_at))
break;
Kernel: Stop walking the stack when we encounter return address 0
2021-04-25 11:39:11 +00:00
if (retaddr == 0)
break;
Kernel: Move perf event backtrace capture out of Thread class There's no need for this to be generic and support running from an arbitrary thread context. Perf events are always generated from within the thread being profiled, so take advantage of that to simplify the code. Also use Vector capacity to avoid heap allocations.
2021-02-03 10:51:13 +00:00
backtrace.append(retaddr);
if (backtrace.size() == PerformanceEvent::max_stack_frame_count)
break;
stack_ptr = stack_ptr_copy;
}
return backtrace;
}
Kernel+Profiler: Improve profiling subsystem This turns the perfcore format into more a log than it was before, which lets us properly log process, thread and region creation/destruction. This also makes it unnecessary to dump the process' regions every time it is scheduled like we did before. Incidentally this also fixes 'profile -c' because we previously ended up incorrectly dumping the parent's region map into the profile data. Log-based mmap support enables profiling shared libraries which are loaded at runtime, e.g. via dlopen(). This enables profiling both the parent and child process for programs which use execve(). Previously we'd discard the profiling data for the old process. The Profiler tool has been updated to not treat thread IDs as process IDs anymore. This enables support for processes with more than one thread. Also, there's a new widget to filter which process should be displayed.
2021-04-25 21:42:36 +00:00
KResult PerformanceEventBuffer::append_with_eip_and_ebp(ProcessID pid, ThreadID tid,
u32 eip, u32 ebp, int type, FlatPtr arg1, FlatPtr arg2, const StringView& arg3)
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
{
if (count() >= capacity())
Kernel+LibC: Turn errno codes into a strongly typed enum ..and allow implicit creation of KResult and KResultOr from ErrnoCode. This means that kernel functions that return those types can finally do "return EINVAL;" and it will just work. There's a handful of functions that still deal with signed integers that should be converted to return KResults.
2021-01-20 22:11:17 +00:00
return ENOBUFS;
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
PerformanceEvent event;
event.type = type;
switch (type) {
Kernel+Profiler: Make profiling per-process and without core dumps This patch merges the profiling functionality in the kernel with the performance events mechanism. A profiler sample is now just another perf event, rather than a dedicated thing. Since perf events were already per-process, this now makes profiling per-process as well. Processes with perf events would already write out a perfcore.PID file to the current directory on death, but since we may want to profile a process and then let it continue running, recorded perf events can now be accessed at any time via /proc/PID/perf_events. This patch also adds information about process memory regions to the perfcore JSON format. This removes the need to supply a core dump to the Profiler app for symbolication, and so the "profiler coredump" mechanism is removed entirely. There's still a hard limit of 4MB worth of perf events per process, so this is by no means a perfect final design, but it's a nice step forward for both simplicity and stability. Fixes #4848 Fixes #4849
2021-01-11 08:52:18 +00:00
case PERF_EVENT_SAMPLE:
break;
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
case PERF_EVENT_MALLOC:
event.data.malloc.size = arg1;
event.data.malloc.ptr = arg2;
break;
case PERF_EVENT_FREE:
event.data.free.ptr = arg1;
break;
Kernel+Profiler: Improve profiling subsystem This turns the perfcore format into more a log than it was before, which lets us properly log process, thread and region creation/destruction. This also makes it unnecessary to dump the process' regions every time it is scheduled like we did before. Incidentally this also fixes 'profile -c' because we previously ended up incorrectly dumping the parent's region map into the profile data. Log-based mmap support enables profiling shared libraries which are loaded at runtime, e.g. via dlopen(). This enables profiling both the parent and child process for programs which use execve(). Previously we'd discard the profiling data for the old process. The Profiler tool has been updated to not treat thread IDs as process IDs anymore. This enables support for processes with more than one thread. Also, there's a new widget to filter which process should be displayed.
2021-04-25 21:42:36 +00:00
case PERF_EVENT_MMAP:
event.data.mmap.ptr = arg1;
event.data.mmap.size = arg2;
memset(event.data.mmap.name, 0, sizeof(event.data.mmap.name));
if (!arg3.is_empty())
memcpy(event.data.mmap.name, arg3.characters_without_null_termination(), min(arg3.length(), sizeof(event.data.mmap.name) - 1));
break;
case PERF_EVENT_MUNMAP:
Kernel: Use the correct union member for unmap events
2021-04-26 21:05:59 +00:00
event.data.munmap.ptr = arg1;
event.data.munmap.size = arg2;
Kernel+Profiler: Improve profiling subsystem This turns the perfcore format into more a log than it was before, which lets us properly log process, thread and region creation/destruction. This also makes it unnecessary to dump the process' regions every time it is scheduled like we did before. Incidentally this also fixes 'profile -c' because we previously ended up incorrectly dumping the parent's region map into the profile data. Log-based mmap support enables profiling shared libraries which are loaded at runtime, e.g. via dlopen(). This enables profiling both the parent and child process for programs which use execve(). Previously we'd discard the profiling data for the old process. The Profiler tool has been updated to not treat thread IDs as process IDs anymore. This enables support for processes with more than one thread. Also, there's a new widget to filter which process should be displayed.
2021-04-25 21:42:36 +00:00
break;
case PERF_EVENT_PROCESS_CREATE:
event.data.process_create.parent_pid = arg1;
memset(event.data.process_create.executable, 0, sizeof(event.data.process_create.executable));
if (!arg3.is_empty()) {
memcpy(event.data.process_create.executable, arg3.characters_without_null_termination(),
min(arg3.length(), sizeof(event.data.process_create.executable) - 1));
}
break;
case PERF_EVENT_PROCESS_EXEC:
memset(event.data.process_exec.executable, 0, sizeof(event.data.process_exec.executable));
if (!arg3.is_empty()) {
memcpy(event.data.process_exec.executable, arg3.characters_without_null_termination(),
min(arg3.length(), sizeof(event.data.process_exec.executable) - 1));
}
break;
case PERF_EVENT_PROCESS_EXIT:
break;
case PERF_EVENT_THREAD_CREATE:
event.data.thread_create.parent_tid = arg1;
break;
case PERF_EVENT_THREAD_EXIT:
break;
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
default:
Kernel+LibC: Turn errno codes into a strongly typed enum ..and allow implicit creation of KResult and KResultOr from ErrnoCode. This means that kernel functions that return those types can finally do "return EINVAL;" and it will just work. There's a handful of functions that still deal with signed integers that should be converted to return KResults.
2021-01-20 22:11:17 +00:00
return EINVAL;
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
}
Kernel: Move perf event backtrace capture out of Thread class There's no need for this to be generic and support running from an arbitrary thread context. Perf events are always generated from within the thread being profiled, so take advantage of that to simplify the code. Also use Vector capacity to avoid heap allocations.
2021-02-03 10:51:13 +00:00
auto backtrace = raw_backtrace(ebp, eip);
AK: Add global FlatPtr typedef. It's u32 or u64, based on sizeof(void*) Use this instead of uintptr_t throughout the codebase. This makes it possible to pass a FlatPtr to something that has u32 and u64 overloads.
2020-03-08 09:36:51 +00:00
event.stack_size = min(sizeof(event.stack) / sizeof(FlatPtr), static_cast<size_t>(backtrace.size()));
memcpy(event.stack, backtrace.data(), event.stack_size * sizeof(FlatPtr));
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
Kernel+Profiler: Improve profiling subsystem This turns the perfcore format into more a log than it was before, which lets us properly log process, thread and region creation/destruction. This also makes it unnecessary to dump the process' regions every time it is scheduled like we did before. Incidentally this also fixes 'profile -c' because we previously ended up incorrectly dumping the parent's region map into the profile data. Log-based mmap support enables profiling shared libraries which are loaded at runtime, e.g. via dlopen(). This enables profiling both the parent and child process for programs which use execve(). Previously we'd discard the profiling data for the old process. The Profiler tool has been updated to not treat thread IDs as process IDs anymore. This enables support for processes with more than one thread. Also, there's a new widget to filter which process should be displayed.
2021-04-25 21:42:36 +00:00
event.pid = pid.value();
event.tid = tid.value();
Kernel: Move some time related code from Scheduler into TimeManagement Use the TimerQueue to expire blocking operations, which is one less thing the Scheduler needs to check on every iteration. Also, add a BlockTimeout class that will automatically handle relative or absolute timeouts as well as overriding timeouts (e.g. socket timeouts) more consistently. Also, rework the TimerQueue class to be able to fire events from any processor, which requires Timer to be RefCounted. Also allow creating id-less timers for use by blocking operations.
2020-11-15 18:58:19 +00:00
event.timestamp = TimeManagement::the().uptime_ms();
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
at(m_count++) = event;
return KSuccess;
}
PerformanceEvent& PerformanceEventBuffer::at(size_t index)
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 19:42:32 +00:00
VERIFY(index < capacity());
Kernel: Use fallible KBuffer API in PerformanceEventBuffer
2020-12-18 19:43:39 +00:00
auto* events = reinterpret_cast<PerformanceEvent*>(m_buffer->data());
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
return events[index];
}
Kernel: Start work on full system profiling :^) The superuser can now call sys$profiling_enable() with PID -1 to enable profiling of all running threads in the system. The perf events are collected in a global PerformanceEventBuffer (currently 32 MiB in size.) The events can be accessed via /proc/profile
2021-03-02 16:19:35 +00:00
template<typename Serializer>
bool PerformanceEventBuffer::to_json_impl(Serializer& object) const
Kernel+Profiler: Make profiling per-process and without core dumps This patch merges the profiling functionality in the kernel with the performance events mechanism. A profiler sample is now just another perf event, rather than a dedicated thing. Since perf events were already per-process, this now makes profiling per-process as well. Processes with perf events would already write out a perfcore.PID file to the current directory on death, but since we may want to profile a process and then let it continue running, recorded perf events can now be accessed at any time via /proc/PID/perf_events. This patch also adds information about process memory regions to the perfcore JSON format. This removes the need to supply a core dump to the Profiler app for symbolication, and so the "profiler coredump" mechanism is removed entirely. There's still a hard limit of 4MB worth of perf events per process, so this is by no means a perfect final design, but it's a nice step forward for both simplicity and stability. Fixes #4848 Fixes #4849
2021-01-11 08:52:18 +00:00
{
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
auto array = object.add_array("events");
for (size_t i = 0; i < m_count; ++i) {
auto& event = at(i);
Kernel: Fix suspicious local shadowing in PerformanceEventBuffer
2020-03-01 20:08:04 +00:00
auto event_object = array.add_object();
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
switch (event.type) {
Kernel+Profiler: Make profiling per-process and without core dumps This patch merges the profiling functionality in the kernel with the performance events mechanism. A profiler sample is now just another perf event, rather than a dedicated thing. Since perf events were already per-process, this now makes profiling per-process as well. Processes with perf events would already write out a perfcore.PID file to the current directory on death, but since we may want to profile a process and then let it continue running, recorded perf events can now be accessed at any time via /proc/PID/perf_events. This patch also adds information about process memory regions to the perfcore JSON format. This removes the need to supply a core dump to the Profiler app for symbolication, and so the "profiler coredump" mechanism is removed entirely. There's still a hard limit of 4MB worth of perf events per process, so this is by no means a perfect final design, but it's a nice step forward for both simplicity and stability. Fixes #4848 Fixes #4849
2021-01-11 08:52:18 +00:00
case PERF_EVENT_SAMPLE:
event_object.add("type", "sample");
break;
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
case PERF_EVENT_MALLOC:
Kernel: Fix suspicious local shadowing in PerformanceEventBuffer
2020-03-01 20:08:04 +00:00
event_object.add("type", "malloc");
event_object.add("ptr", static_cast<u64>(event.data.malloc.ptr));
event_object.add("size", static_cast<u64>(event.data.malloc.size));
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
break;
case PERF_EVENT_FREE:
Kernel: Fix suspicious local shadowing in PerformanceEventBuffer
2020-03-01 20:08:04 +00:00
event_object.add("type", "free");
event_object.add("ptr", static_cast<u64>(event.data.free.ptr));
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
break;
Kernel+Profiler: Improve profiling subsystem This turns the perfcore format into more a log than it was before, which lets us properly log process, thread and region creation/destruction. This also makes it unnecessary to dump the process' regions every time it is scheduled like we did before. Incidentally this also fixes 'profile -c' because we previously ended up incorrectly dumping the parent's region map into the profile data. Log-based mmap support enables profiling shared libraries which are loaded at runtime, e.g. via dlopen(). This enables profiling both the parent and child process for programs which use execve(). Previously we'd discard the profiling data for the old process. The Profiler tool has been updated to not treat thread IDs as process IDs anymore. This enables support for processes with more than one thread. Also, there's a new widget to filter which process should be displayed.
2021-04-25 21:42:36 +00:00
case PERF_EVENT_MMAP:
event_object.add("type", "mmap");
event_object.add("ptr", static_cast<u64>(event.data.mmap.ptr));
event_object.add("size", static_cast<u64>(event.data.mmap.size));
event_object.add("name", event.data.mmap.name);
break;
case PERF_EVENT_MUNMAP:
event_object.add("type", "munmap");
event_object.add("ptr", static_cast<u64>(event.data.munmap.ptr));
event_object.add("size", static_cast<u64>(event.data.munmap.size));
break;
case PERF_EVENT_PROCESS_CREATE:
event_object.add("type", "process_create");
event_object.add("parent_pid", static_cast<u64>(event.data.process_create.parent_pid));
event_object.add("executable", event.data.process_create.executable);
break;
case PERF_EVENT_PROCESS_EXEC:
event_object.add("type", "process_exec");
event_object.add("executable", event.data.process_exec.executable);
break;
case PERF_EVENT_PROCESS_EXIT:
event_object.add("type", "process_exit");
break;
case PERF_EVENT_THREAD_CREATE:
event_object.add("type", "thread_create");
event_object.add("parent_tid", static_cast<u64>(event.data.thread_create.parent_tid));
break;
case PERF_EVENT_THREAD_EXIT:
event_object.add("type", "thread_exit");
break;
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
}
Kernel+Profiler: Improve profiling subsystem This turns the perfcore format into more a log than it was before, which lets us properly log process, thread and region creation/destruction. This also makes it unnecessary to dump the process' regions every time it is scheduled like we did before. Incidentally this also fixes 'profile -c' because we previously ended up incorrectly dumping the parent's region map into the profile data. Log-based mmap support enables profiling shared libraries which are loaded at runtime, e.g. via dlopen(). This enables profiling both the parent and child process for programs which use execve(). Previously we'd discard the profiling data for the old process. The Profiler tool has been updated to not treat thread IDs as process IDs anymore. This enables support for processes with more than one thread. Also, there's a new widget to filter which process should be displayed.
2021-04-25 21:42:36 +00:00
event_object.add("pid", event.pid);
Kernel+Profiler: Make profiling per-process and without core dumps This patch merges the profiling functionality in the kernel with the performance events mechanism. A profiler sample is now just another perf event, rather than a dedicated thing. Since perf events were already per-process, this now makes profiling per-process as well. Processes with perf events would already write out a perfcore.PID file to the current directory on death, but since we may want to profile a process and then let it continue running, recorded perf events can now be accessed at any time via /proc/PID/perf_events. This patch also adds information about process memory regions to the perfcore JSON format. This removes the need to supply a core dump to the Profiler app for symbolication, and so the "profiler coredump" mechanism is removed entirely. There's still a hard limit of 4MB worth of perf events per process, so this is by no means a perfect final design, but it's a nice step forward for both simplicity and stability. Fixes #4848 Fixes #4849
2021-01-11 08:52:18 +00:00
event_object.add("tid", event.tid);
Kernel: Fix suspicious local shadowing in PerformanceEventBuffer
2020-03-01 20:08:04 +00:00
event_object.add("timestamp", event.timestamp);
auto stack_array = event_object.add_array("stack");
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
for (size_t j = 0; j < event.stack_size; ++j) {
stack_array.add(event.stack[j]);
}
stack_array.finish();
Kernel: Fix suspicious local shadowing in PerformanceEventBuffer
2020-03-01 20:08:04 +00:00
event_object.finish();
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
}
array.finish();
object.finish();
Kernel+Profiler: Make profiling per-process and without core dumps This patch merges the profiling functionality in the kernel with the performance events mechanism. A profiler sample is now just another perf event, rather than a dedicated thing. Since perf events were already per-process, this now makes profiling per-process as well. Processes with perf events would already write out a perfcore.PID file to the current directory on death, but since we may want to profile a process and then let it continue running, recorded perf events can now be accessed at any time via /proc/PID/perf_events. This patch also adds information about process memory regions to the perfcore JSON format. This removes the need to supply a core dump to the Profiler app for symbolication, and so the "profiler coredump" mechanism is removed entirely. There's still a hard limit of 4MB worth of perf events per process, so this is by no means a perfect final design, but it's a nice step forward for both simplicity and stability. Fixes #4848 Fixes #4849
2021-01-11 08:52:18 +00:00
return true;
Kernel: Start working on a syscall for logging performance events This patch introduces sys$perf_event() with two event types: - PERF_EVENT_MALLOC - PERF_EVENT_FREE After the first call to sys$perf_event(), a process will begin keeping these events in a buffer. When the process dies, that buffer will be written out to "perfcore" in the current directory unless that filename is already taken. This is probably not the best way to do this, but it's a start and will make it possible to start doing memory allocation profiling. :^)
2020-02-02 19:26:27 +00:00
}
Kernel: Move all code into the Kernel namespace
2020-02-16 00:27:42 +00:00
Kernel+Profiler: Capture metadata about all profiled processes The perfcore file format was previously limited to a single process since the pid/executable/regions data was top-level in the JSON. This patch moves the process-specific data into a top-level array named "processes" and we now add entries for each process that has been sampled during the profile run. This makes it possible to see samples from multiple threads when viewing a perfcore file with Profiler. This is extremely cool! :^)
2021-03-02 18:01:02 +00:00
bool PerformanceEventBuffer::to_json(KBufferBuilder& builder) const
Kernel: Start work on full system profiling :^) The superuser can now call sys$profiling_enable() with PID -1 to enable profiling of all running threads in the system. The perf events are collected in a global PerformanceEventBuffer (currently 32 MiB in size.) The events can be accessed via /proc/profile
2021-03-02 16:19:35 +00:00
{
JsonObjectSerializer object(builder);
return to_json_impl(object);
}
Kernel: Better handling of allocation failure in profiling If we can't allocate a PerformanceEventBuffer to store the profiling events, we now fail sys$profiling_enable() and sys$perf_event() with ENOMEM instead of carrying on with a broken buffer.
2021-03-02 15:55:54 +00:00
OwnPtr<PerformanceEventBuffer> PerformanceEventBuffer::try_create_with_size(size_t buffer_size)
{
auto buffer = KBuffer::try_create_with_size(buffer_size, Region::Access::Read | Region::Access::Write, "Performance events", AllocationStrategy::AllocateNow);
if (!buffer)
return {};
return adopt_own(*new PerformanceEventBuffer(buffer.release_nonnull()));
}
Kernel+Profiler: Improve profiling subsystem This turns the perfcore format into more a log than it was before, which lets us properly log process, thread and region creation/destruction. This also makes it unnecessary to dump the process' regions every time it is scheduled like we did before. Incidentally this also fixes 'profile -c' because we previously ended up incorrectly dumping the parent's region map into the profile data. Log-based mmap support enables profiling shared libraries which are loaded at runtime, e.g. via dlopen(). This enables profiling both the parent and child process for programs which use execve(). Previously we'd discard the profiling data for the old process. The Profiler tool has been updated to not treat thread IDs as process IDs anymore. This enables support for processes with more than one thread. Also, there's a new widget to filter which process should be displayed.
2021-04-25 21:42:36 +00:00
void PerformanceEventBuffer::add_process(const Process& process, ProcessEventType event_type)
Kernel+Profiler: Capture metadata about all profiled processes The perfcore file format was previously limited to a single process since the pid/executable/regions data was top-level in the JSON. This patch moves the process-specific data into a top-level array named "processes" and we now add entries for each process that has been sampled during the profile run. This makes it possible to see samples from multiple threads when viewing a perfcore file with Profiler. This is extremely cool! :^)
2021-03-02 18:01:02 +00:00
{
ScopedSpinLock locker(process.space().get_lock());
String executable;
if (process.executable())
executable = process.executable()->absolute_path();
Kernel+Profiler: Improve profiling subsystem This turns the perfcore format into more a log than it was before, which lets us properly log process, thread and region creation/destruction. This also makes it unnecessary to dump the process' regions every time it is scheduled like we did before. Incidentally this also fixes 'profile -c' because we previously ended up incorrectly dumping the parent's region map into the profile data. Log-based mmap support enables profiling shared libraries which are loaded at runtime, e.g. via dlopen(). This enables profiling both the parent and child process for programs which use execve(). Previously we'd discard the profiling data for the old process. The Profiler tool has been updated to not treat thread IDs as process IDs anymore. This enables support for processes with more than one thread. Also, there's a new widget to filter which process should be displayed.
2021-04-25 21:42:36 +00:00
else
executable = String::formatted("<{}>", process.name());
[[maybe_unused]] auto rc = append_with_eip_and_ebp(process.pid(), 0, 0, 0,
event_type == ProcessEventType::Create ? PERF_EVENT_PROCESS_CREATE : PERF_EVENT_PROCESS_EXEC,
Kernel: Avoid calling characters() where not necessary
2021-04-26 21:06:58 +00:00
process.pid().value(), 0, executable);
Kernel+Profiler: Capture metadata about all profiled processes The perfcore file format was previously limited to a single process since the pid/executable/regions data was top-level in the JSON. This patch moves the process-specific data into a top-level array named "processes" and we now add entries for each process that has been sampled during the profile run. This makes it possible to see samples from multiple threads when viewing a perfcore file with Profiler. This is extremely cool! :^)
2021-03-02 18:01:02 +00:00
process.for_each_thread([&](auto& thread) {
Kernel+Profiler: Improve profiling subsystem This turns the perfcore format into more a log than it was before, which lets us properly log process, thread and region creation/destruction. This also makes it unnecessary to dump the process' regions every time it is scheduled like we did before. Incidentally this also fixes 'profile -c' because we previously ended up incorrectly dumping the parent's region map into the profile data. Log-based mmap support enables profiling shared libraries which are loaded at runtime, e.g. via dlopen(). This enables profiling both the parent and child process for programs which use execve(). Previously we'd discard the profiling data for the old process. The Profiler tool has been updated to not treat thread IDs as process IDs anymore. This enables support for processes with more than one thread. Also, there's a new widget to filter which process should be displayed.
2021-04-25 21:42:36 +00:00
[[maybe_unused]] auto rc = append_with_eip_and_ebp(process.pid(), thread.tid().value(),
0, 0, PERF_EVENT_THREAD_CREATE, 0, 0, nullptr);
Kernel+Profiler: Capture metadata about all profiled processes The perfcore file format was previously limited to a single process since the pid/executable/regions data was top-level in the JSON. This patch moves the process-specific data into a top-level array named "processes" and we now add entries for each process that has been sampled during the profile run. This makes it possible to see samples from multiple threads when viewing a perfcore file with Profiler. This is extremely cool! :^)
2021-03-02 18:01:02 +00:00
return IterationDecision::Continue;
});
for (auto& region : process.space().regions()) {
Kernel+Profiler: Improve profiling subsystem This turns the perfcore format into more a log than it was before, which lets us properly log process, thread and region creation/destruction. This also makes it unnecessary to dump the process' regions every time it is scheduled like we did before. Incidentally this also fixes 'profile -c' because we previously ended up incorrectly dumping the parent's region map into the profile data. Log-based mmap support enables profiling shared libraries which are loaded at runtime, e.g. via dlopen(). This enables profiling both the parent and child process for programs which use execve(). Previously we'd discard the profiling data for the old process. The Profiler tool has been updated to not treat thread IDs as process IDs anymore. This enables support for processes with more than one thread. Also, there's a new widget to filter which process should be displayed.
2021-04-25 21:42:36 +00:00
[[maybe_unused]] auto rc = append_with_eip_and_ebp(process.pid(), 0,
Kernel: Avoid calling characters() where not necessary
2021-04-26 21:06:58 +00:00
0, 0, PERF_EVENT_MMAP, region->range().base().get(), region->range().size(), region->name());
Kernel+Profiler: Capture metadata about all profiled processes The perfcore file format was previously limited to a single process since the pid/executable/regions data was top-level in the JSON. This patch moves the process-specific data into a top-level array named "processes" and we now add entries for each process that has been sampled during the profile run. This makes it possible to see samples from multiple threads when viewing a perfcore file with Profiler. This is extremely cool! :^)
2021-03-02 18:01:02 +00:00
}
}
Kernel: Move all code into the Kernel namespace
2020-02-16 00:27:42 +00:00
}
Reference in a new issue Copy permalink