Paths forward: (not mutually exclusive) A: !site -> fill from backing store
1st try at this is/was using zram. At init, it copied each callsite into a zs-allocation, and all site-> refs afterward went thru _get/_put to zs-map on demand, and zs-unmap the site info. This worked until I tried to keep callsites mapped while they're enabled. Another approach is to compress the new linker section, using some algo thats good at indexed decompression. I tried to test this a bit, using objcopy, unsuccessfully: objcopy --dump-section __dyndbg_callsites=dd_callsites vmlinux.o >From vmlinux.o it was mostly empty, vmlinux didnt have the section. B: callsite as a set of property vectors, indexed by 'N' We know dp is in a vector, either in the builtin __dyndbg_callsite linker section, or the same from a modprobed one. The builtin section has all builtin module sub-sections catenated dogether. At init, we iterate over the section, and "parse it" by creating a ddebug_table for each module with prdebugs. ddebug_table.num_debugs remembers the size of each modules' vector of prdebugs. We need a few things: - _ddebug.index field, which knows offset to start of this sub-vector. this new field will be "free" because the struct has padding. it can be initialized during init, then RO. - a back-pointer at the beginning of the sub-vector, to the ddebug_table "owning" (but not containing) this sub-vector of prdebugs. If we had both, we could get from the ddebug element to its vector root, back up to the owning ddebug_table, then down to the _callsite vector, and index to the right element. While slower than a pointer deref, this is a cold path, and it allows elimination of the per-callsite pointer member, thus greater density of the sections, and still can support sparse site info. That back-pointer feels tricky. It needs to be 1st in the sub-vector is to reserve the 0th slot ing its spot at the front of each module's ddebug sub-vector. getting space in the section for it. Initializing it is easy. prdebugs are added to section when DECLARE_DYAMIC_DEBUG_METADATA is compiled; its unclear whether they are intrinsically sorted during compile, or whether thats a linker thing. Ideally, a MODULE-mumble declaration can be coaxed into declaring a module singleton in the section(s), either naturally at the top (or bottom) or sorted into place. If that doesn't work, a "preload if module is different" strategy could maybe work, but I dont know how to do that in macros. Signed-off-by: Jim Cromie <jim.cro...@gmail.com> --- lib/dynamic_debug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index 25f49515c235..ec28c113a361 100644 --- a/lib/dynamic_debug.c +++ b/lib/dynamic_debug.c @@ -146,7 +146,7 @@ static void vpr_info_dq(const struct ddebug_query *query, const char *msg) static struct _ddebug_callsite *ddebug_site_get(struct _ddebug *dp) { - return dp->site; + return dp->site; /* passthru abstraction */ } static inline void ddebug_site_put(struct _ddebug *dp) { -- 2.29.2