On Tue, 2018-11-06 at 13:05 -0800, Andrew Morton wrote: > On Fri, 2 Nov 2018 12:25:20 -0700 Rick Edgecombe <rick.p.edgecombe@xxxxxxxxx> > wrote: > > > This adds a test module in lib/, and a script in kselftest that does > > benchmarking on the allocation of memory in the module space. Performance > > here > > would have some small impact on kernel module insertions, BPF JIT insertions > > and kprobes. In the case of KASLR features for the module space, this module > > can be used to measure the allocation performance of different > > configurations. > > This module needs to be compiled into the kernel because module_alloc is not > > exported. > > Well, we could export module_alloc(). Would that be helpful at all? For me at least, it wasn't an issue to compile it into the kernel, since its just for development testing. Since its controlled through debugfs, it doesn't do anything until you write to it. > > With some modification to the code, as explained in the comments, it can be > > enabled to measure TLB flushes as well. > > > > There are two tests in the module. One allocates until failure in order to > > test module capacity and the other times allocating space in the module > > area. > > They both use module sizes that roughly approximate the distribution of in- > > tree > > X86_64 modules. > > > > You can control the number of modules used in the tests like this: > > echo m1000>/dev/mod_alloc_test > > > > Run the test for module capacity like: > > echo t1>/dev/mod_alloc_test > > > > The other test will measure the allocation time, and for CONFG_X86_64 and > > CONFIG_RANDOMIZE_BASE, also give data on how often the “backup area" is > > used. > > > > Run the test for allocation time and backup area usage like: > > echo t2>/dev/mod_alloc_test > > The output will be something like this: > > num all(ns) last(ns) > > 1000 1083 1099 > > Last module in backup count = 0 > > Total modules in backup = 0 > > > 1 module in backup count = 0 > > Are the above usage instructions captured in the kernel code somewhere? > I can't see it, and expecting people to trawl git changelogs isn't > very friendly. > Thanks. I'll add the instructions to the file. For the performance test, a script is included that does everything needed.
