Recording where modules were loaded in perf.data

While trying to fix the build-id generation so as not to produce duplicates, I noticed another problem that needs to be solved before we can introduce perf archive and be able to analyse a perf.data file recorded in one machine on another, possibly with a different architecture and OS.

The problem is similar to the relocatable kernel problem solved today: we need to have perf events that state where kernel modules were loaded, right now we are using the current /proc/modules to get that information, but it can no longer have some modules, unloaded after perf record and before perf report.

To properly fix that we need the kernel infrastructure to emit PERF_MODULE_LOAD/PERF_MODULE_UNLOAD events just like it does when DSOs get loaded by means of executable mmap, when it emits PERF_MMAP/PERF_MUNMAP events, so that there are no races and we can support long running perf record sessions where modules get loaded/unloaded.

Tomorrow I’ll work on synthesizing such events in perf record and then when all works we can do the kernel bits and stop synthesizing then in user space.

About these ads
Post a comment or leave a trackback: Trackback URL.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: