All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Amir Goldstein <amir73il@gmail.com>
Cc: lsf-pc@lists.linux-foundation.org,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Jan Kara <jack@suse.cz>, Dave Chinner <david@fromorbit.com>
Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] automating file system benchmarks
Date: Fri, 13 Dec 2019 10:35:47 -0500	[thread overview]
Message-ID: <20191213153547.GA273569@mit.edu> (raw)
In-Reply-To: <CAOQ4uxhxx4EdaAsSPOztbx+0gfhixSi4fhBrhtDji1Dn4hgrow@mail.gmail.com>

On Fri, Dec 13, 2019 at 07:12:03AM +0200, Amir Goldstein wrote:
> 
> Very nice :)
> You should post an [ANNOUNCE] every now and then.
> I rarely check upstream of xfstests-bld, because it just-works ;-)

Right now, the PTS support in gce-xfstests is very manual.  Right now
the VM is launched via "gce-xfstests pts", then you have to log into
the VM, "gce-xfstests ssh pts" after a few minutes, then run
"phoronix-test-suite pts/disk", answer a few questions, and then
afterwards run "pts-save --results" and then kill off the pts VM.

I want to get it to the point where "gce-xfstests pts" is sufficient,
where the benchmarks are run and the VM is automatically shut down
afterwards.  Also still to be done is to add support for kvm-xfstests.
That'll hopefully be done in the next month or so, as I have some free
time.

> I suppose you have access to a dedicated metal in the cloud for running
> your performance regression tests? Or at least a dedicated metal per execution.

I'm not currently using a dedicated VM currently.  I've been primarily
using a 1TB PD-SSD as the storage medium and a n1-standard-16 as the
VM type.  That's been fairly reliable.

Using GCE Local SSD is a little tricky because there is more than one
underlying hardware, and that can result in differing results across
different VM's.  What you *can* do is to just use the same VM, and
then kexec into different kernels each time.  This can be done
manually, by copying in a different kernel into /root/bzImage, and
then running /root/do_kexec, and then running the next benchmark.
Eventually my plan to support this with a  command like

gce-xfstests --kernel gs://$B/bzImage-4.19,gs://bz/$B/bzImage-5.3 \
	--local-ssd pts

The reason why Local SSD is interesting is that GCE's Persistent Disk
has a very different performance profile than HDD's or SSD's --- it
acts much more like a battery-backed enterprise storage array, in that
CACHE FLUSH's are super fast, as are random writes.  GCE Local SSD
acts like, well, a real high performance SSD, and it's good to
benchmark both.

> I have not looked into GCE, so don't know how easy it is and how expensive
> to use GCE this way.

A benchmark run does take longer than "gce-xfstests -g auto", since
you generally use a larger VM and a larger amount of storage.  A 1T
PD-SSD plus a n1-standard-16 VM is about a dollar an hour, and it's
3-4 hours to run the pts/disk benchmark suite.  So call it $3-4 for a
single performance test run.

> Is there any chance of Google donating this sort of resource for a performance
> regression test bot?

We're not at the point where we could run gce-xfstests (either for
functional or performance testing) as a bot.  There's still some
development work that needs to happen before that could be a reality.
For now, if there was a development team that wanted to use
gce-xfstests for performance and benchmarking, I'm happy to put them
in contact with the folks at Google which support open source
projects.

   	     		       	   		   - Ted

      reply	other threads:[~2019-12-13 20:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-13  1:47 [LSF/MM/BPF TOPIC] automating file system benchmarks Theodore Y. Ts'o
2019-12-13  5:12 ` [Lsf-pc] " Amir Goldstein
2019-12-13 15:35   ` Theodore Y. Ts'o [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=20191213153547.GA273569@mit.edu \
    --to=tytso@mit.edu \
    --cc=amir73il@gmail.com \
    --cc=david@fromorbit.com \
    --cc=jack@suse.cz \
    --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 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.