From: Christoph Hellwig <hch@lst.de>
To: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Cc: kbusch@kernel.org, hch@lst.de, linux-nvme@lists.infradead.org,
sagi@grimberg.me
Subject: Re: [PATCH V4 2/2] nvme-core: use xarray for ctrl ns tracking
Date: Mon, 20 Jul 2020 15:34:54 +0200 [thread overview]
Message-ID: <20200720133454.GA2837@lst.de> (raw)
In-Reply-To: <20200720033203.11474-3-chaitanya.kulkarni@wdc.com>
On Sun, Jul 19, 2020 at 08:32:03PM -0700, Chaitanya Kulkarni wrote:
> This patch replaces the ctrl->namespaces tracking from linked list to
> xarray and improves the performance. For host even though
> nvme_find_get_ns() doesn't fall into the fast path yet it does for
> NVMeOF passthru patch-series which is currently under review. This
> prepares us to improve performance for future NVMeOF passthru backend
> since nvme_find_get_ns() uses same data structure as it does in target
> to find namespace in I/O patch from nsid specified in the nvme_rw_cmd.
І'm still not really sold on that rationale..
> + if (xa_empty(&ctrl->namespaces)) {
> ret = -ENOTTY;
> - goto out_unlock;
> + goto out;
> }
> -
> - ns = list_first_entry(&ctrl->namespaces, struct nvme_ns, list);
> - if (ns != list_last_entry(&ctrl->namespaces, struct nvme_ns, list)) {
> - dev_warn(ctrl->device,
> - "NVME_IOCTL_IO_CMD not supported when multiple namespaces present!\n");
> - ret = -EINVAL;
> - goto out_unlock;
> + xa_for_each(&ctrl->namespaces, idx, ns) {
> + if (count > 0)
> + goto err;
> + count++;
How about factoring the check into a little
nvme_has_multiple_namespaces helper and avoid the backwards jumping
goto later on?
> + rcu_read_lock();
> + ns = xa_load(&ctrl->namespaces, nsid);
> + ns = ns && kref_get_unless_zero(&ns->kref) ? ns : NULL;
> + rcu_read_unlock();
The canonical way to write this is:
rcu_read_lock();
ns = xa_load(&ctrl->namespaces, nsid);
if (ns && !kref_get_unless_zero(&ns->kref))
ns = NULL;
rcu_read_unlock();
> + out_unregister_nvm:
Maybe call this out_unregister_lightnvm to be a little more descriptive.
> +
> + xa_lock(&ctrl->namespaces);
> + xa_for_each(&ctrl->namespaces, idx, ns) {
> + tnsid = ns->head->ns_id;
> + if (tnsid > nsid || test_bit(NVME_NS_DEAD, &ns->flags)) {
> + __xa_erase(&ctrl->namespaces, tnsid);
> + xa_unlock(&ctrl->namespaces);
> + /* Even if insert fails keep going */
> + ret = xa_insert(&rm_array, nsid, ns, GFP_KERNEL);
> + if (ret)
> + pr_err("xa_insert %d\n", ret);
> + xa_lock(&ctrl->namespaces);
> + }
And this is where I'm still worried that we now need an insert
as part of the namespace deletion. Either keep the list here as
I suggested before, or we just need rework the deletion here first.
> @@ -4119,11 +4114,18 @@ void nvme_remove_namespaces(struct nvme_ctrl *ctrl)
> if (ctrl->state == NVME_CTRL_DEAD)
> nvme_kill_queues(ctrl);
>
> - down_write(&ctrl->namespaces_rwsem);
> - list_splice_init(&ctrl->namespaces, &ns_list);
> - up_write(&ctrl->namespaces_rwsem);
> + xa_lock(&ctrl->namespaces);
> + xa_for_each(&ctrl->namespaces, idx, ns) {
> + __xa_erase(&ctrl->namespaces, ns->head->ns_id);
> + xa_unlock(&ctrl->namespaces);
> + ret = xa_insert(&rm_array, ns->head->ns_id, ns, GFP_KERNEL);
> + if (ret)
> + pr_err("xa_insert %d\n", ret);
> + xa_lock(&ctrl->namespaces);
> + }
> + xa_unlock(&ctrl->namespaces);
Same here.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2020-07-20 13:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-20 3:32 [PATCH V4 0/2] nvme: use xarray for ns tracking Chaitanya Kulkarni
2020-07-20 3:32 ` [PATCH V4 1/2] nvmet: use xarray for ctrl ns storing Chaitanya Kulkarni
2020-07-20 13:30 ` Christoph Hellwig
2020-07-20 3:32 ` [PATCH V4 2/2] nvme-core: use xarray for ctrl ns tracking Chaitanya Kulkarni
2020-07-20 13:34 ` Christoph Hellwig [this message]
2020-07-20 19:41 ` Sagi Grimberg
2020-07-20 21:32 ` 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=20200720133454.GA2837@lst.de \
--to=hch@lst.de \
--cc=chaitanya.kulkarni@wdc.com \
--cc=kbusch@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.