On 1/23/19 11:37 PM, Daniel Colascione wrote:
While I think there's definitely a place for eBPF as part of the
Android performance toolkit, I think most users will end up using it
through rich front-end performance collection and analysis tools (of
the sort I'm working on) rather than directly as a first-line window
into the operation of the system.
Sure, I don't disagree.
Below this level is probably
something like bpftrace, and below that, raw eBPF and ftrace
manipulation. It's also worth noting that much of the time, system
analysis is retrospection, not inspection (e.g., investigating the
causes of rare and hard-to-reproduce bad behavior), and so iteration
via interactive specification of eBPF programs isn't a practical path
forward. It's still useful, even in this scenario, to be able (as part
of higher-level tools) attach "canned" eBPF programs to the kernel to
extract certain generally-useful bits of information, and in this
capacity, Joel's header module would be useful.
Hmm. Not sure I agree about that. There's no reason I can't use Android
Studio to "right-click" on a line of code or even a span of code and
select a "trace this in detail for me" option, where "in detail" could
mean different things depending on the code that's highlighted. Doing
I/O calls? Then automatically measure some I/O benchmarks for that
portion of code. Doing graphics calls? Do the same for the graphics
stack, etc.
Personally I advocated a more aggressive approach with Joel in private:
just put the darn headers straight into the kernel image, it's the
*only* artifact we're sure will follow the Android device whatever
happens to it (like built-in ftrace).
I was thinking along similar lines. Ordinarily, we make loadable
kernel modules. What we kind of want here is a non-loadable kernel
module --- or a non-loadable section in the kernel image proper. I'm
not familiar with early-stage kernel loader operation: I know it's
possible to crease discardable sections in the kernel image, but can
we create sections that are never slurped into memory in the first
place? If not, maybe loading and immediately discarding the header
section is good enough.
Interesting. Maybe just append it to the image but have it not loaded
and have a kernel parameter than enables a "/proc/kheaders" driver to
know where the fetch the appended headers from storage at runtime. There
would be no RAM loading whatsoever of the headers, just some sort of
"kheaders=/dev/foobar:offset:size" parameter. If you turn the option on,
you get a fatter kernel image size to store on permanent storage, but no
impact on what's loaded at boot time.
Would such a thing really do better than LZMA? LZMA already has very
clever techniques for eliminating long-range redundancies in
compressible text, including redundancies at the sub-byte level. I can
certainly understand the benefit of stripping comments, since removing
comments really does decrease the total amount of information the
compressor has to preserve, but I'm not sure how much the encoding
scheme you propose below would help, since it reminds me of the
encoding scheme that LZMA would discover automatically.
I'm no compression algorithm expert. If you say LZMA would do the
same/better than what I suggested then I have no reason to contest that.
My goal is to see the headers as part of the kernel image that's
distributed on devices so that they don't have to be chased around. I'm
just trying to make it as palatable as possible.
Whether such craziness makes sense or is adopted or not isn't mine to
chart, but I certainly can't see eBPF reaching the same mass deployment
ftrace has within the Android ecosystem until there's a way to use it
without having to chase kernel headers independently of kernel images.
There are "too many clicks" involved and someone somewhere will drop the
ball if it's not glued to the kernel in some way shape or form. Any
solution that solves this is one I'd love to hear about.
I agree. There definitely needs to be a "just collect a damn trace"
button that works on any device, and for this button to work and
incorporate eBPF, the system needs to be able to describe itself.
I like that: "the system needs to be able to describe itself". True.
Cheers,
--
Karim Yaghmour
CEO - Opersys inc. / www.opersys.com
http://twitter.com/karimyaghmour
