linux-kernel - Re: [PATCH] lightnvm: calculate device values correctly

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACygaLB37AFsGqVPM-qkT-bHEBJ89nemF8v0pcgK=JjENbHqmQ@mail.gmail.com>
Date:	Mon, 23 Nov 2015 10:26:24 +0800
From:	Wenwei Tao <ww.tao0320@...il.com>
To:	Matias <mb@...htnvm.io>
Cc:	linux-kernel@...r.kernel.org, linux-block@...r.kernel.org
Subject: Re: [PATCH] lightnvm: calculate device values correctly

OK, I see. Thanks for the explanation.

2015-11-23 2:34 GMT+08:00 Matias <mb@...htnvm.io>:
> 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@...il.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/