[RFC v1 0/1] nvme testsuite runtime optimization
Chaitanya Kulkarni
chaitanyak at nvidia.com
Wed Apr 19 02:34:55 PDT 2023
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
More information about the Linux-nvme
mailing list