mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chaitanya Kulkarni <chaitanyak@nvidia.com>
To: Daniel Wagner <dwagner@suse.de>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	Chaitanya Kulkarni <chaitanyak@nvidia.com>,
	Shin'ichiro Kawasaki <shinichiro@fastmail.com>
Subject: Re: [RFC v1 0/1] nvme testsuite runtime optimization
Date: Wed, 19 Apr 2023 09:34:55 +0000	[thread overview]
Message-ID: <f0d2ddd5-37d6-8fba-a5e3-965fb9f41474@nvidia.com> (raw)
In-Reply-To: <20230419085643.25714-1-dwagner@suse.de>

On 4/19/23 01:56, Daniel Wagner wrote:
> While testing the fc transport I got a bit tired of wait for the I/O jobs to
> finish. Thus here some runtime optimization.
>
> With a small/slow VM I got following values:
>
> with 'optimizations'
>    loop:
>      real    4m43.981s
>      user    0m17.754s
>      sys     2m6.249s
>
>    rdma:
>      real    2m35.160s
>      user    0m6.264s
>      sys     0m56.230s
>
>    tcp:
>      real    2m30.391s
>      user    0m5.770s
>      sys     0m46.007s
>
>    fc:
>      real    2m19.738s
>      user    0m6.012s
>      sys     0m42.201s
>
> base:
>    loop:
>      real    7m35.061s
>      user    0m23.493s
>      sys     2m54.866s
>
>    rdma:
>      real    8m29.347s
>      user    0m13.078s
>      sys     1m53.158s
>
>    tcp:
>      real    8m11.357s
>      user    0m13.033s
>      sys     2m43.156s
>
>    fc:
>      real    5m46.615s
>      user    0m12.819s
>      sys     1m46.338s
>
>

Those jobs are meant to be run for at least 1G to establish
confidence on the data set and the system under test since SSDs
are in TBs nowadays and we don't even get anywhere close to that,
with your suggestion we are going even lower ...

we cannot change the dataset size for slow VMs, instead add
a command line argument and pass it to tests e.g.
nvme_verification_size=XXX similar to nvme_trtype but don't change
the default values which we have been testing for years now

Testing is supposed to be time consuming especially verification jobs..

-ck



  parent reply	other threads:[~2023-04-19  9:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-19  8:56 Daniel Wagner
2023-04-19  8:56 ` [RFC v1 1/1] nvme: Limit runtime for verification and limit test image size Daniel Wagner
2023-04-19  9:34 ` Chaitanya Kulkarni [this message]
2023-04-19  9:50   ` [RFC v1 0/1] nvme testsuite runtime optimization Sagi Grimberg
2023-04-19 11:10     ` Daniel Wagner
2023-04-19 13:15       ` Sagi Grimberg
2023-04-19 21:13         ` Chaitanya Kulkarni
2023-04-19 21:11     ` Chaitanya Kulkarni
2023-04-20  8:24       ` Daniel Wagner
2023-04-20  8:31         ` Daniel Wagner
2023-04-19 21:31     ` Chaitanya Kulkarni

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=f0d2ddd5-37d6-8fba-a5e3-965fb9f41474@nvidia.com \
    --to=chaitanyak@nvidia.com \
    --cc=dwagner@suse.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=shinichiro@fastmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®