From: Sean Christopherson <seanjc@google.com>
To: David Matlack <dmatlack@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
kvm list <kvm@vger.kernel.org>, Ben Gardon <bgardon@google.com>,
Colton Lewis <coltonlewis@google.com>,
Ricardo Koller <ricarkol@google.com>,
Andrew Jones <andrew.jones@linux.dev>
Subject: Re: [RFC PATCH 0/2] KVM: selftests: Rename perf_test_util to memstress
Date: Tue, 26 Jul 2022 17:45:03 +0000 [thread overview]
Message-ID: <YuAoH9NZHbKzC6Az@google.com> (raw)
In-Reply-To: <CALzav=e6ZODi1Cpv5Ej9uWWC_zF1eMMJqbXYHhi+fgenfgsfow@mail.gmail.com>
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.
prev parent reply other threads:[~2022-07-26 17:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-25 16:35 [RFC PATCH 0/2] KVM: selftests: Rename perf_test_util to memstress David Matlack
2022-07-25 16:35 ` [RFC PATCH 1/2] KVM: selftests: Rename perf_test_util.[ch] to memstress.[ch] David Matlack
2022-07-25 16:35 ` [RFC PATCH 2/2] KVM: selftests: Rename perf_test_util symbols to memstress David Matlack
2022-07-25 16:57 ` [RFC PATCH 0/2] KVM: selftests: Rename perf_test_util " Andrew Jones
2022-07-25 22:44 ` Sean Christopherson
2022-07-26 17:29 ` David Matlack
2022-07-26 17:45 ` Sean Christopherson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YuAoH9NZHbKzC6Az@google.com \
--to=seanjc@google.com \
--cc=andrew.jones@linux.dev \
--cc=bgardon@google.com \
--cc=coltonlewis@google.com \
--cc=dmatlack@google.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=ricarkol@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.