From: Matias <mb@lightnvm.io>
To: Wenwei Tao <ww.tao0320@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org
Subject: Re: [PATCH] lightnvm: calculate device values correctly
Date: Sun, 22 Nov 2015 19:34:04 +0100 [thread overview]
Message-ID: <56520A9C.2030502@lightnvm.io> (raw)
In-Reply-To: <1448200278-10272-1-git-send-email-ww.tao0320@gmail.com>
On 11/22/2015 02:51 PM, Wenwei Tao wrote:
> In the original calculation, the relationships among
> block, plane and lun was confusing, refine it on the
> basis of Open-channelSSDInterfaceSpecification.
>
> Signed-off-by: Wenwei Tao <ww.tao0320@gmail.com>
> ---
> drivers/lightnvm/core.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
> index f659e60..1864b94 100644
> --- a/drivers/lightnvm/core.c
> +++ b/drivers/lightnvm/core.c
> @@ -174,8 +174,8 @@ static int nvm_core_init(struct nvm_dev *dev)
> dev->nr_chnls = grp->num_ch;
> dev->luns_per_chnl = grp->num_lun;
> dev->pgs_per_blk = grp->num_pg;
> - dev->blks_per_lun = grp->num_blk;
> dev->nr_planes = grp->num_pln;
> + dev->blks_per_lun = grp->num_blk * grp->num_pln;
> dev->sec_size = grp->csecs;
> dev->oob_size = grp->sos;
> dev->sec_per_pg = grp->fpg_sz / grp->csecs;
> @@ -191,13 +191,12 @@ static int nvm_core_init(struct nvm_dev *dev)
> dev->plane_mode = NVM_PLANE_QUAD;
>
> /* calculated values */
> - dev->sec_per_pl = dev->sec_per_pg * dev->nr_planes;
> - dev->sec_per_blk = dev->sec_per_pl * dev->pgs_per_blk;
> + dev->sec_per_blk = dev->sec_per_pg * dev->pgs_per_blk;
> + dev->sec_per_pl = dev->sec_per_blk * grp->num_blk;
> dev->sec_per_lun = dev->sec_per_blk * dev->blks_per_lun;
> dev->nr_luns = dev->luns_per_chnl * dev->nr_chnls;
>
> - dev->total_blocks = dev->nr_planes *
> - dev->blks_per_lun *
> + dev->total_blocks = dev->blks_per_lun *
> dev->luns_per_chnl *
> dev->nr_chnls;
> dev->total_pages = dev->total_blocks * dev->pgs_per_blk;
>
The reason I had it as before, was because I wanted to drive the device
in either single/double/quad read/write/erase plane mode. That way we
could get away with only managing 1/4 or 1/2 of the block metadata.
What is your use case? It could make sense, but it will require a little
more work to build up the framework for having the various modes. i.e.
detect supported plane mode, make a explicit decision about which plane
mode to always use (or dynamically) and afterwards allocate the
appropriate data structures.
next prev parent reply other threads:[~2015-11-22 18:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-22 13:51 [PATCH] lightnvm: calculate device values correctly Wenwei Tao
2015-11-22 14:05 ` Wenwei Tao
2015-11-22 18:34 ` Matias [this message]
2015-11-23 2:26 ` Wenwei Tao
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=56520A9C.2030502@lightnvm.io \
--to=mb@lightnvm.io \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ww.tao0320@gmail.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 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.