[PATCH 0/8] mmap_cache subsystem (re-factoring)
yamato at redhat.com
Tue Apr 24 05:25:14 UTC 2018
> On Tue, Feb 27, 2018 at 02:30:06AM +0300, Dmitry V. Levin wrote:
>> On Sat, Jan 27, 2018 at 05:36:36AM +0900, Masatake YAMATO wrote:
>> > When we added unwinding feature (activated with -k option), we also added
>> > a code for caching the entries of /proc/$pid/maps.
>> > The code for caching was tightly integrated with the code for
>> > unwinding. However, while prototyping kvm vcpu state dump feature to
>> > strace, I found the code for caching is useful for other purposes
>> > than unwinding feature.
>> > This patch set makes the code for caching usable independently of
>> > unwinding feature. In the changes, I call the newly separated
>> > code for caching "mmap_cache subsystem".
>> >  https://marc.info/?l=kvm&m=151531408406144&w=2
>> > Masatake YAMATO (8):
>> > unwind: lift up unw_flush_cache from mmap cache management code
>> > Introduce mmap_cache subsystem derived from unwind.c
>> > mmap_cache: Move code for searching an mmap cache from unwind
>> > mmap_cache: record protection bits
>> > Lift up mmap_cache_delete invocation from unwind.c
>> > mmap_cache: add function to enable mmap_cache
>> > mmap_cache: record device major and minor numbers
>> > mmap_cache: add customizable search function
>> Thanks, I'll merge the first 7 of them, with minor corrections
>> (mostly related to commit messages) and a single build fix.
> With introduction of libdw-based unwinder this mmap_cache subsystem looks
> very odd: despite the fact that libdw-based unwinder does not use mmap_cache,
> it's use is forced by unwind.c for no visible purpose.
mmap_cache calls tcb_flush_cache (and dwfl_linux_proc_report) when
the memory mapping of a target process is changed.
It is useful when the target process
loads a library dynamically with dlopen though it is not perfect.
> Could something be done to avoid initialization of mmap_cache subsystem
> unless it's really needed?
More information about the Strace-devel