From: Chaitanya Kulkarni <chaitanyak@nvidia.com>
To: Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
Chaitanya Kulkarni <chaitanyak@nvidia.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: Re: [PATCH] nvme: add nvme pci timeout testcase
Date: Thu, 11 Jan 2024 00:00:22 +0000 [thread overview]
Message-ID: <f730071b-1183-4266-8a12-0f044b8f9bc3@nvidia.com> (raw)
In-Reply-To: <wa3xm2v53vsgcs3iv4f3fy477zza6uwxj64dwib6ib27kmkgxj@ovgndmtcpzch>
On 1/10/2024 4:23 AM, Shinichiro Kawasaki wrote:
> Thanks again for this test case. Please find my review comments. Tomorrow, I
> will try to run this test case.
>
> On Jan 09, 2024 / 19:57, Chaitanya Kulkarni wrote:
>> Trigger and test nvme-pci timeout with concurrent fio jobs.
>
> Is there any related kernel commit which motivated this test case? If so,
> can we add a kernel commit or e-mail discussion link as a reference?
>
no, this part if never tested on the regular basis as it has some
complicated logic I believe it is much needed test ..
>>
>> Signed-off-by: Chaitanya Kulkarni <kch@nvidia.com>
>> ---
>> tests/nvme/050 | 43 +++++++++++++++++++++++++++++++++++++++++++
>> tests/nvme/050.out | 2 ++
>> 2 files changed, 45 insertions(+)
>> create mode 100755 tests/nvme/050
>> create mode 100644 tests/nvme/050.out
>>
>> diff --git a/tests/nvme/050 b/tests/nvme/050
>> new file mode 100755
>> index 0000000..ba54bcd
>> --- /dev/null
>> +++ b/tests/nvme/050
>> @@ -0,0 +1,43 @@
>> +#!/bin/bash
>> +# SPDX-License-Identifier: GPL-3.0+
>> +# Copyright (C) 2024 Chaitanya Kulkarni.
>
> Nit: you may want to remove the last '.'
okay ...
>
>> +#
>> +# Test NVMe-PCI timeout with FIO jobs by triggering the nvme_timeout function.
>> +#
>> +
>> +. tests/nvme/rc
>> +
>> +DESCRIPTION="test nvme-pci timeout with fio jobs."
>
> To be consitent with other test cases, let's remove the last '.'.
okay ...
>
>> +
>> +requires() {
>> + _require_nvme_trtype pci
>> + _have_fio
>> + _nvme_requires
>
> This test case depends on the kernel config FAIL_IO_TIMEOUT. Let's add
>
> _have_kernel_option FAIL_IO_TIMEOUT
indeed, I'll add that ...
>
>> +}
>> +
>> +test() {
>> + local dev="/dev/nvme0n1"
>> +
>> + echo "Running ${TEST_NAME}"
>> +
>> + echo 1 > /sys/block/nvme0n1/io-timeout-fail
>> +
>> + echo 99 > /sys/kernel/debug/fail_io_timeout/probability
>> + echo 10 > /sys/kernel/debug/fail_io_timeout/interval
>> + echo -1 > /sys/kernel/debug/fail_io_timeout/times
>> + echo 0 > /sys/kernel/debug/fail_io_timeout/space
>> + echo 1 > /sys/kernel/debug/fail_io_timeout/verbose
>
> To avoid impact on following test cases, I suggest to restore the original
> values of the fail_io_timeout/* sysfs attributes above at the end of this
> test case. _nvme_err_inject_setup() and _nvme_err_inject_cleanup() in
> test/nvme/rc do similar thing. We can add new helper functions in same manner.
I can add the code for config and restore, but at this point there are
no other testcases using this ?(correct me if I'm wrong), so instead of
bloating the code in nvme/rc let's keep it for this testcase only ?
and add common helpers code later once we have more users for this
case ?
>
>> +
>> + # shellcheck disable=SC2046
>> + fio --bs=4k --rw=randread --norandommap --numjobs=$(nproc) \
>
> Double quotes for "$(nproc)" will allow to remove the shellcheck exception,
> probably.
not sure I understand this comment, can you please elaborate ?
>
>> + --name=reads --direct=1 --filename=${dev} --group_reporting \
>> + --time_based --runtime=1m 2>&1 | grep -q "Input/output error"
>> +
>> + # shellcheck disable=SC2181
>> + if [ $? -eq 0 ]; then
>> + echo "Test complete"
>> + else
>> + echo "Test failed"
>> + fi
>> + modprobe -r nvme
>
> If nvme driver is built-in, this unload command does not work.
> Do we really need to unload nvme driver here?
>
Yes, post timeout handler execution we need to make sure that device
can be removed at the time of module unload, perhaps there is a way to
avoid this when nvme is a built-in module so that test will not execute
above ? any suggestions ?
-ck
next prev parent reply other threads:[~2024-01-11 0:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20240110062350epcas5p351f5b4f8e27b3c57545b49509d2a48b6@epcas5p3.samsung.com>
2024-01-10 3:57 ` [PATCH] nvme: add nvme pci timeout testcase Chaitanya Kulkarni
2024-01-10 6:17 ` Nitesh Shetty
2024-01-10 7:40 ` Chaitanya Kulkarni
2024-01-10 7:54 ` Nitesh Shetty
2024-01-10 8:12 ` Chaitanya Kulkarni
2024-01-10 9:13 ` Shinichiro Kawasaki
2024-01-10 9:24 ` Hannes Reinecke
2024-01-10 23:47 ` Chaitanya Kulkarni
2024-01-10 14:59 ` Jens Axboe
2024-01-10 23:51 ` Chaitanya Kulkarni
2024-01-10 12:23 ` Shinichiro Kawasaki
2024-01-11 0:00 ` Chaitanya Kulkarni [this message]
2024-01-11 4:41 ` Shinichiro Kawasaki
2024-01-11 5:01 ` Chaitanya Kulkarni
2024-01-11 1:25 ` Yi Zhang
2024-01-11 3:09 ` 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=f730071b-1183-4266-8a12-0f044b8f9bc3@nvidia.com \
--to=chaitanyak@nvidia.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=shinichiro.kawasaki@wdc.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