From: Guenter Roeck <linux@roeck-us.net>
To: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@lst.de>,
Keith Busch <keith.busch@intel.com>,
Sagi Grimberg <sagi@grimberg.me>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] nvme: default to 0 poll queues
Date: Sat, 8 Dec 2018 16:49:53 -0800 [thread overview]
Message-ID: <20181209004953.GA11638@roeck-us.net> (raw)
Hi,
On Mon, Nov 19, 2018 at 08:18:24AM -0700, Jens Axboe wrote:
> We need a better way of configuring this, and given that polling is
> (still) a bit niche, let's default to using 0 poll queues. That way
> we'll have the same read/write/poll behavior as 4.20, and users that
> want to test/use polling are required to do manual configuration of the
> number of poll queues.
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Jens Axboe <axboe@kernel.dk>
> ---
This patch results in a boot stall when booting parisc (hppa) images
from nvme in qemu.
...
Fusion MPT SAS Host driver 3.04.20
rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
rcu: (detected by 0, t=5252 jiffies, g=141, q=22)
rcu: All QSes seen, last rcu_sched kthread activity 5252 (-66742--71994), jiffies_till_next_fqs=1, root ->qsmask 0x0
kworker/u8:3 R running task 0 85 2 0x00000004
Workqueue: nvme-reset-wq nvme_reset_work
Backtrace:
[<10190d20>] show_stack+0x28/0x38
[<101dd1e0>] sched_show_task.part.3+0xc4/0x144
[<101dd290>] sched_show_task+0x30/0x38
[<10221e18>] rcu_check_callbacks+0x760/0x7a4
rcu: rcu_sched kthread starved for 5252 jiffies! g141 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
rcu: RCU grace-period kthread stack dump:
rcu_sched R running task 0 10 2 0x00000000
Backtrace:
[<10995b1c>] __schedule+0x214/0x648
[<10995f94>] schedule+0x44/0xa8
[<1099a7c4>] schedule_timeout+0x114/0x1a0
[<10220e70>] rcu_gp_kthread+0x744/0x968
[<101d5438>] kthread+0x154/0x15c
[<1019501c>] ret_from_kernel_thread+0x1c/0x24
[ continued ]
This is only seen in SMP configurations; non-SMP configurations are ok.
Reverting the patch fixes the problem. v4.20-rcX and earlier kernels
also boot without problems.
For reference, here is the qemu command line. This is with qemu 3.0.
qemu-system-hppa -kernel vmlinux -no-reboot \
-snapshot \
-device nvme,serial=foo,drive=d0 \
-drive file=rootfs.ext2,if=none,format=raw,id=d0 \
-append 'root=/dev/nvme0n1 rw rootwait panic=-1 console=ttyS0,115200 ' \
-nographic -monitor null
Please let me know if you need additional information.
Thanks,
Guenter
next reply other threads:[~2018-12-09 0:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-09 0:49 Guenter Roeck [this message]
2018-12-09 5:38 ` [PATCH] nvme: default to 0 poll queues Jens Axboe
2018-12-09 6:22 ` Guenter Roeck
2018-12-09 6:31 ` Jens Axboe
2018-12-09 7:32 ` Guenter Roeck
2018-12-09 18:18 ` Jens Axboe
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=20181209004953.GA11638@roeck-us.net \
--to=linux@roeck-us.net \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=keith.busch@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/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