This is a SysprofInstrument that will eventually contain the contents of
the sysprof-battery-source.c to get battery charge/rate/etc. Note that
this is different from energy usage which will come from RAPL.
This uses G_REGEX_OPTIMIZE as well to get the benefit of the JIT when using
PCRE2 via GLib.
This turns out to take about half (or less) of the time that it takes to
use sscanf() to parse the template/input string. 0.03 vs 0.08 seconds on
my system.
If someone wants to take this further, and just look at the input string
rather than rely on GRegex, that'd be fine by me too.
We will always have either \n or \0 at the end, so we can just sscanf this
without needing to split strings.
The sscanf() is still our top offender though, and so we should probably
look for other ways to parse this string than sscanf().
That is the instrument that really provides things within the kernel
address space, so it should be the instrument which copies the contents
of kallsyms to the capture file (compressed).
We have a fairly large buffer for perf events, so we should be able to
process these much less frequently to help reduce the process performing
the profile from showing up in the profiling results.
It is not enough to get writability, as that wont trigger on the perf
source. Instead, we need to check the mmap'd header and drive things off
of that.
It might be nice to eventually determine how many of the samples are from
our own process and back-off our timeout based on that.
This starts porting the old perf code from libsysprof into
libsysprof-profile. It does not bring over tracepoints yet, because we
need to think about how we want to support that. I may opt to do that as
a separate instrument even if that takes an additional perf fd.
This is a bit different than how we did things previously, but the same
mechanics are involved. Instead of multiple CPU registered together, we'll
just use one-stream-per-cpu.
Partly because I intend to drop support for profiling a single process as
that doesn't really get used much nor does it seem to yield very good
results from perf.
We can use the new infinite future here to mimic running forever when there
is no spawnable. Otherwise, if the spawnable exits we want to break out
of the recording loop.
I'd like to stop using tracefd, but since we need to maintain compatability
with older tooling, lets at least make it more ergonomic than adding an
instrument(s) for it.
The goal here is to do the whole thing on a fiber rather than how we were
doing it before. This just gets the counter registration going, but we
need to follow up with the parsing/lseek/etc code.
