From: Chaitanya Kulkarni <chaitanyak@nvidia.com>
To: Sagi Grimberg <sagi@grimberg.me>, 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>,
Shin'ichiro Kawasaki <shinichiro@fastmail.com>
Subject: Re: [RFC v1 0/1] nvme testsuite runtime optimization
Date: Wed, 19 Apr 2023 21:11:33 +0000 [thread overview]
Message-ID: <27235520-2e63-2891-fd0a-ff758f18032e@nvidia.com> (raw)
In-Reply-To: <9a1f1709-baaf-5661-2cbf-c34e2da9e42e@grimberg.me>
On 4/19/23 02:50, Sagi Grimberg 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
>
> How come loop is doubling the time with this patch?
> ratio is not the same before and after.
>
>>>
>>> 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 ...
>
> Where does the 1G boundary coming from?
>
I wrote these testcases 3 times, initially they were the part of
nvme-cli tests7-8 years ago, then nvmftests 7-6 years ago, then they
moved to blktests.
In that time some of the testcases would not fail on with small size
such as less than 512MB especially with verification but they were
in the errors with 1G Hence I kept to be 1G.
Now I don't remember why I didn't use bigger size than 1G
should have documented that somewhere ...
>> 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..
>
> I like the idea, but I think it may need to be the other way around.
> Have shortest possible runs by default.
see above..
-ck
next prev parent reply other threads:[~2023-04-19 21:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-19 8:56 [RFC v1 0/1] nvme testsuite runtime optimization 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 ` [RFC v1 0/1] nvme testsuite runtime optimization Chaitanya Kulkarni
2023-04-19 9:50 ` 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 [this message]
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=27235520-2e63-2891-fd0a-ff758f18032e@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=sagi@grimberg.me \
--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;
as well as URLs for NNTP newsgroup(s).