Re: [PATCH] enhance kernel profiling to loadable modules

[hirao]

 Hello, Keith
 Thank you for the comment. 

> Instead of patching kernel/module.c and maintaining a separate list of
> module related profiling data, use the kernel_data field in struct
> module.  I added that field specificially so to track any kernel data
> that relates to each module.
 It is necessary to use kernel_data field in struct module. I see. 

> Change the module_arch_init() and free_module() functions in
> include/asm-i386/module.h to allocate and free the kernel_data
> structure during module load and unload.  Take the profile lock in
> those routines (disabling interrupts) when you update kernel_data.
 Certainly, I made patch for the x86 architecture. 
 However, I guessed that neither creation nor free of profiling buffer
would depend on architecture. 
 And, I had it write these processing (create_module_profile(),
delete_module_profile()) in kernel/profile.c, and call from module(). 
 Isn't this idea correct?
 If it is not correct, it is necessary to inpriment as processing of
the architecture dependence like your point it. 

> 
> To map a profile eip to a module, run the module list looking for the
> address, see kernel_text_address() in arch/i386/kernel/traps.c for
> example code.
> 
> With this approach, the mainline module code is unchanged, all arch
> specific profile code is in include/asm-$(ARCH)/module.h.
> 
> Your srch_prof_buffer() algorithm is ix86 specific, you assume that
> modules are always above the end of the kernel.  That is not true on
> all architectures.  The correct method is to treat the kernel as just
> another module and store the profile data for the kernel in
> kernel_module.kernel_data, using arch_init_modules().  Running the
> module list (which includes the kernel itself) will find the correct
> address range in an architecture portable way.  Add one extra slot to
> the kernel profile table for out of range addresses.
 It is so. Processing which specifies module from eip is corrected as
shown in the point. 

-- 
hirao <[e-mail]>