Message ID | 20220725163539.3145690-1-dmatlack@google.com (mailing list archive) |
---|---|
Headers | show |
Series | KVM: selftests: Rename perf_test_util to memstress | expand |
On Mon, Jul 25, 2022 at 04:35:37PM +0000, 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). > > - "memstress" contains the same number of characters as "perf_test", making > it a drop in replacement in symbols wihout changing line lengths. > > - The lack of underscore between "mem" and "stress" makes it clear "memstress" > is a noun, avoiding confusion in function names. Naming is hard, acking rename patches that have good justifications is easy. For the series, Acked-by: Andrew Jones <andrew.jones@linux.dev>
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. Maybe mmu_perf or something along those lines? I wouldn't worry too much about changing the number of chars, the churn wouldn't be thaaat bad.
On Mon, Jul 25, 2022 at 3:45 PM Sean Christopherson <seanjc@google.com> 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.
On Tue, Jul 26, 2022, David Matlack wrote: > On Mon, Jul 25, 2022 at 3:45 PM Sean Christopherson <seanjc@google.com> 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). Yeah, I don't disagree on any point, it's purely that memstress makes me think of memtest (the pre-boot test that blasts memory with patterns to detect bad DRAM). > > 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. Let's go with your original "memstress". I like how it looks in code, and once I get past the initial "memtest" association, it's a good fit. > Another contender was "memstorm", but I thought it might be too cute. Heh. mem_minions? Then we can have "mm_args" and really confuse everyone.