The full system profiling functionality is useful for profiling the
boot performance of the system. Add a new kernel boot option to start
the system with profiling enabled. This lets you disable and view a
profile once the system is booted.
You can use it by running:
```
$ run.sh qcmd boot_prof
```
Previously all of the CommandLine parsing was spread out around the
Kernel. Instead move it all into the Kernel CommandLine class, and
expose a strongly typed API for querying the state of options.
Previously, the instruction fetch flag of the page fault handler
did not have the currect binary representation, and would always
return false. This aligns these flags.
Because the z-order changes we not only need to recompute occlusions
but we also need to mark the screen area of the previous and new
highlighted window as dirty.
Fixes#5599
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! :^)
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
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.
When you reset() a Track, you need to set the piano roll iterators back
to the first notes.
Fixes#2578. The bug was due to pressing export between 2 notes - the
tracks were never told to go back to the first note.
This was the original approach before we switched to get_fast_random()
which wasn't fast enough, so we added a buffer.
Unfortunately that buffer is racy and we can actually skid past the end
of it and continue fetching "random" offsets from the adjacent memory
for a while, until we run out of kernel data segment and trip a fault.
Instead of making this even more convoluted, let's just go back to the
pleasantly simple (RDTSC & 0xff) approach. :^)
Fixes#4912.
When a mousewheel scroll event isn't handled by the web content
itself (e.g. an overflowed box or similar), the event needs to get
passed back up to the OutOfProcessWebView.
We try scrolling a Node with the handle_mousewheel event, but if it
isn't scrollable, the event should be passed back up to the page
host. This is the first step in that process.
Instead of assuming that we should use the OSC 9 progress messages
whenever we run on serenity, add a show-progress=[true|false] option.
This lets us avoid seeing esc sequence spam in GitHub Actions logs.
I don't dare touch the multi-threading logic and locking mechanism, so it stays
timespec for now. However, this could and should be changed to AK::Time, and I
bet it will simplify the "increment_time_since_boot()" code.
This commit is very invasive, because Thread likes to take a pointer and write
to it. This means that translating between timespec/timeval/Time would have been
more difficult than just changing everything that hands a raw pointer to Thread,
in bulk.
These structs can be inconsistent, for example if the amount of microseconds is
negative or larger than 1'000'000. Therefore, they should not be copied as-is.
Use copy_time_from_user instead.
copy_from_user can fail, for example when the user-supplied pointer is just before
the end of mapped address space. In that case, the first few bytes would get copied,
permanently overwriting the internal state of the Socket, potentially leaving it
in an inconsistent or at least difficult-to-predict state.
