Currently only Ext2FS and TmpFS supports InodeWatchers. We now fail
with ENOTSUPP if watch_file() is called on e.g ProcFS.
This fixes an issue with FileManager chewing up all the CPU when /proc
was opened. Watchers don't keep the watched Inode open, and when they
close, the watcher FD will EOF.
Since nothing else kept /proc open in FileManager, the watchers created
for it would EOF immediately, causing a refresh over and over.
Fixes#879.
I had to change the layout of RegisterDump a little bit to make the new
IRQ entry points work. This broke get_register_dump_from_stack() which
was expecting the RegisterDump to be badly aligned due to a goofy extra
16 bits which are no longer there.
This logic is all taken care of by GAbstractColumnView now, so we can
simply delete GTreeView::context_menu_event(). :^)
Fixes an issue mentioned in #826
Instead of having a common entry point and looking at the PIC ISR to
figure out which IRQ we're servicing, just make a separate entryway
for each IRQ that pushes the IRQ number and jumps to a common routine.
This fixes a weird issue where incoming network packets would sometimes
cause the mouse to stop working. I didn't track it down further than
realizing we were sometimes EOI'ing the wrong IRQ.
Instead of fetching these from JSON in every paint event, we now have a
separate "SampleData" vector that can be iterated.
This optimization was made possible by profiling ProfileViewer and then
analyzing the profile with ProfileViewer! :^)
You can now select the time range you want on the profile timeline.
The tree view will update automatically as you alter the range.
Unfortunately this causes the treeview to collapse all of its nodes.
It would be nice to solve this somehow in the future so that nodes
can stay open.
The majority of the time in NetworkTask was being spent in allocating
and deallocating KBuffers for each incoming packet.
We'll now keep up to 100 buffers around and reuse them for new packets
if the next incoming packet fits in an old buffer. This is pretty
naively implemented but definitely cuts down on time spent here.
4KB gets pretty mmap/munmap heavy when downloading larger files,
so bump this a bit to reduce time spent in memory allocation.
This can be improved in various ways, but I'm not sure what the
best way forward is at the moment.
Since stream sockets don't actually need to deliver packets-at-a-time
data in recvfrom(), they can just buffer the payload bytes instead.
This avoids keeping one KBuffer per incoming packet in the receive
queue, which was a big performance issue in ProtocolServer.
This code is definitely not perfect and is something we should keep
improving over time.
This makes GTreeView able to support multi-column models!
Only one column can be the "tree column", this is column 0 by default
but can be changed by overriding GModel::tree_column().
The squad is complete :^)
You can find the equation for the triangle wave here:
https://en.wikipedia.org/wiki/Triangle_wave
We're using this one:
|x mod 4 - 2| - 1
Modifications have been made to correct the frequency and phase:
|(4x + 1) mod 4 - 2| - 1
The white noise is generated by calling rand() and dividing it by
RAND_MAX to get a value from 0 to 1. Then it's adjusted to fit between
-1 and 1.
When the filesystem model is updated, it is rebuilt. This means dangling
indexes inside the TreeView metadata table will have old information and random
directories will toggle open. Clearing the table alleviates this issue.
We begin with a simple treeview that shows a recorded profile.
To record and view a profile of a process with <PID>, simply do this:
$ profile <PID> on
... wait while PID does something interesting ...
$ profile <PID> off
$ cat /proc/profile > my-profile.prof
$ ProfileViewer my-profile.prof
This is pretty large but since it's not eagerly committed to physical
pages, it's probably okay. I'm bumping this after running out of space
for a ProtocolServer profile run :^)
This adds a context menu to the TreeView with the ability to copy/paste, create
new directories, etc. This does not address the issue mentioned above where
using the global application shortcut does not apply to whatever view has
focus.
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
