[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5duh22ydzwth2z2sd4oo22cuaqlazxq3u5m7vo5qfkp4fgec7w@elzdr6vbksgv>
Date: Fri, 19 May 2023 01:36:17 +0000
From: Shinichiro Kawasaki <shinichiro.kawasaki@....com>
To: Chaitanya Kulkarni <chaitanyak@...dia.com>
CC: Daniel Wagner <dwagner@...e.de>,
"linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
Shin'ichiro Kawasaki <shinichiro@...tmail.com>,
Hannes Reinecke <hare@...e.de>
Subject: Re: [PATCH blktests v4 09/11] nvme{045,047}: Calculate IO size for
random fio jobs
On May 17, 2023 / 04:44, Chaitanya Kulkarni wrote:
> On 5/11/23 07:09, Daniel Wagner wrote:
> > _nvme_calc_run_io_size() returns the jobs size for _run_fio_rand_io()
> > function. The jobs size is the size per job, thus we have to divide
> > through the number of CPUs.
>
> sorry I didn't understand why we have to divide through number of
> CPUs ? isn't tht will change the current job size of the test ?
>
> unless we are increasing somewhere which I missed it .
This change reduces the I/O size per job, but it keeps the total I/O size
regardless of the number of CPUs. This will keep test case runtime reasonable
on systems with hundreds of CPUs.
As for the test case nvme/045, it tests re-authentication. I don't think it
requires total I/O size proportional to number of CPUs. As for the test case
nvme/047, it exercises different queue types (write queue and poll queue). Does
it require total I/O size proportional to number of CPUs? Daniel is the test
case author, and I guessed he is ok with the change.
Powered by blists - more mailing lists