From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966171AbcA1JJu (ORCPT ); Thu, 28 Jan 2016 04:09:50 -0500 Received: from mail-wm0-f50.google.com ([74.125.82.50]:38616 "EHLO mail-wm0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753197AbcA1JJl (ORCPT ); Thu, 28 Jan 2016 04:09:41 -0500 Subject: Re: [PATCH v2 2/2] lightnvm: add non-continuous lun target creation support To: Wenwei Tao References: <1453811633-3721-1-git-send-email-ww.tao0320@gmail.com> <1453811633-3721-2-git-send-email-ww.tao0320@gmail.com> <56A89169.6030704@lightnvm.io> Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org From: =?UTF-8?Q?Matias_Bj=c3=b8rling?= Message-ID: <56A9DAD2.8030300@lightnvm.io> Date: Thu, 28 Jan 2016 10:09:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/28/2016 09:50 AM, Wenwei Tao wrote: > 2016-01-27 17:44 GMT+08:00 Matias Bjørling : >> On 01/26/2016 01:33 PM, Wenwei Tao wrote: >>> When create a target, we specify the begin lunid and >>> the end lunid, and get the corresponding continuous >>> luns from media manager, if one of the luns is not free, >>> we failed to create the target, even if the device's >>> total free luns are enough. >>> >>> So add non-continuous lun target creation support, >>> thus we can improve the backend device's space utilization. >>> Signed-off-by: Wenwei Tao >>> --- >>> Changes since v1: >>> -use NVM_FIXED instead NVM_C_FIXED in gennvm_get_lun >>> -add target creation flags check >>> -rebase to v4.5-rc1 >>> >>> drivers/lightnvm/core.c | 36 ++++--- >>> drivers/lightnvm/gennvm.c | 42 ++++++++- >>> drivers/lightnvm/rrpc.c | 215 +++++++++++++++++++++++++++--------------- >>> drivers/lightnvm/rrpc.h | 6 +- >>> include/linux/lightnvm.h | 24 ++++- >>> include/uapi/linux/lightnvm.h | 3 + >>> 6 files changed, 229 insertions(+), 97 deletions(-) >>> >> >> Hi Wenwei, >> >> I did some digging on the patch and changed the interface to a >> reserve/release interface. I also removed the logic to dynamically >> select another lun than the one requested. >> >> A couple of questions: >> >> 1. The rrpc_lun->rev_lock and rev_trans_map change; this might be for >> another patch, and it isn't directly related to continuous mapping? > > rrpc_lun->rev_lock and rev_trans_map change is related to > non-continuous mapping, it's not directly related to continuous > mapping. > Put this change in another patch along with non-continuous mapping > support and this patch would be only add reserve/release thing, is > that your suggestion? Yes, that would be great. Then we keep it separate. I'll like to do some benchmarks with the patch on and off, to see the performance difference. > >> 2. Instead of dynamically assigning new luns when not available, what >> about taking a list of lun ids instead? >> > > Seems you prefer user make the choice ? Yes, I want it to be deterministic. For example, if we do it dynamically, the user might first allocate 2-4, and then allocate 1-3 , which will actually allocate 0,1,5. Then later, a user tries to allocate on 0, and instead gets returned 6. It quickly makes it difficult to use. > But the target creation can still fail if one of the list lun ids is > not available although there may be enough free luns. Agree, the user would have to look up the free luns and then resubmit the target allocation.