On Mon, Jul 25, 2022 at 3:45 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > On Mon, Jul 25, 2022, David Matlack wrote: > > This series renames the perf_test_util to memstress. patch 1 renames the files > > perf_test_util.[ch] to memstress.[ch], and patch 2 replaces the perf_test_ > > prefix on symbols with memstress_. > > > > The reason for this rename, as with any rename, is to improve readability. > > perf_test_util is too generic and does not describe at all what the library > > does, other than being used for perf tests. > > > > I considered a lot of different names (naming is hard) and eventually settled > > on memstress for a few reasons: > > > > - "memstress" better describes the functionality proveded by this library, > > which is to run a VM that reads/writes to memory from all vCPUs in parallel > > (i.e. stressing VM memory). > > Hmm, but the purpose of the library isn't to stress VM memory so much as it is to > stress KVM's MMU. And typically "stress" tests just hammer a resource to try and > make it fail, whereas measuring performance is one of the main > > In other words, IMO it would be nice to keep "perf" in there somehwere. The reasons I leaned toward "stress" rather than "perf" is that this library itself does not measure performance (it's just a workload) and it's not always used for performance tests (e.g. memslot_modification_stress_test.c). > > Maybe mmu_perf or something along those lines? How about "memperf"? "mmu_perf" makes me think it'd be explicitly measuring the performance of MMU operations. Another contender was "memstorm", but I thought it might be too cute. > I wouldn't worry too much about > changing the number of chars, the churn wouldn't be thaaat bad. Heh. The line lengths were getting long when I played with "memory_stress" :). But yeah it's not really that much churn.
