From: Josef Bacik <josef@toxicpanda.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: lsf-pc@lists.linux-foundation.org, Josef Bacik <jbacik@fb.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
fstests <fstests@vger.kernel.org>, Eryu Guan <eguan@redhat.com>
Subject: Re: [LSF/MM TOPIC] Filesystem performance regression tests
Date: Thu, 1 Feb 2018 09:21:40 -0500 [thread overview]
Message-ID: <20180201142139.5a53brni5rnjciyp@destiny> (raw)
In-Reply-To: <CAOQ4uxi+L6Bhs_=aTvNemC9wBXHw0_bwwPixNzFcJoc8e79XsQ@mail.gmail.com>
On Thu, Feb 01, 2018 at 08:50:21AM +0200, Amir Goldstein wrote:
> Hi Josef and all,
>
> I would like to be rude and solicit a talk from Josef on automated
> performance regression testing (if he is planning to attend).
> We know the guys at facebook are running some performance
> regression tests for a while and Josef has just upstreamed
> a nice taste on this infrastructure to xfstests:
> https://marc.info/?l=fstests&m=150765617921864&w=2
>
> But this is only the beginning... for community performance
> regression tests to be useful there need to be not only people
> running the tests, but also people running the tests on well known
> machines and/or well known hardware configurations and maintain
> long lived performance results db for those machines.
>
> How can we utilize community resources to achieve that?
> Can running performance regressions of gce-xfstests provide
> anything close to stable results?
>
> If performance regressions are integrated into 0-day kernel test
> robot, that could be extremely beneficial to the community, but can
> the robot guaranty to run the tests on dedicated machines or
> VMs with dedicated resources?
>
> Do we know of good examples to follow from automated regression
> tests done for specific filesystem (Dave Chinner has referred to his
> regression tests in one or two occasions)? for other kernel subsystems?
>
> Putting up a regression test server for overlayfs is on my TODO list.
> In the mean while, I have little to contribute from my experience, but
> would love to sit in that talk.
>
I'm happy to talk about this stuff and how it could be improved. I think
integrating it into continuous testing is tricky. With all of our performance
stuff it's always A/B testing, because shit changes constantly. I hate doing
perf stuff in VM's because it's captive to whatever else the host is doing.
xfstests is a good place for this stuff since we all have our own personal rigs
that we control. Could we extend xfstests to log our results publicly? That
would be cool, I would be fine with that. My test box rarely changes, so if its
just a matter of uploading some magic ID associated with my box, and then
uploading results paired with that ID to be world viewed then that would be
cool. I'm sure we could find somebody willing to host such a thing for us.
Thanks,
Josef
next prev parent reply other threads:[~2018-02-01 14:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-01 6:50 [LSF/MM TOPIC] Filesystem performance regression tests Amir Goldstein
2018-02-01 14:21 ` Josef Bacik [this message]
2018-02-02 0:19 ` Dave Chinner
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=20180201142139.5a53brni5rnjciyp@destiny \
--to=josef@toxicpanda.com \
--cc=amir73il@gmail.com \
--cc=eguan@redhat.com \
--cc=fstests@vger.kernel.org \
--cc=jbacik@fb.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).