Received: by 10.192.165.156 with SMTP id m28csp1737061imm; Tue, 17 Apr 2018 04:50:02 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/f3fPtgzE78kuS9C/3p1XaeLl48Q5BHCs41VBYhlSyW+mOpLNB5eNbtwg/YNltiX5+wmVL X-Received: by 10.98.4.133 with SMTP id 127mr1708588pfe.26.1523965802834; Tue, 17 Apr 2018 04:50:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523965802; cv=none; d=google.com; s=arc-20160816; b=qbwN36asKlaJ3TObR6RiX6txVP6+cJsjOOoWTzdiiowzvwZpo0x65q69YmPfUC7Dok jIwkJ/mhCwZikDEzsptAgkrNpeEkHSMT/rgDC6uy6364zcUgbpJNDqEVSOKZCx0LX36a jtrFY+ykU0m3ulAPxj/GriYTXdpzvFbKAsOhOi3HuAx6In8WylvornW2KZ2GllP0oOec jnp1phoDfQmKF2qivhDjwD2AiOrmC5RrMLoPmGRSMnDxZT98mjklg8SLUlm/vZlK4DKN j4oWkE8qmKUW9XWBZ6O4BHPBbi751m1y7mmLs8bhF5dd9fwnc4wlKtwY32bU4Dv8XtDr ezyg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=Hq+GnHOCuDzAwyPGxeqA+/ZegYzR3Z/XkaPxP3Zezdk=; b=PXK8EFtDi1mrN05/wrDbiYOf5hLCg06qoDnJEKF+M+/1Ia8OZIPgi3+GTXVTRwxNtD FRCdoXlAvMA99iuF3gy6VSlpXO5G8HMYzn0lb+FQS39V6tEvpO7ve5Qsd0cLyD1EO7zO NsTJbr5c9FEO0pn3kPBjww6Z7AaN3ocNmZzReBjW3oTtpZ288HeT8ZCEkA+GNg6JULaW kImN+/uDuP1I24sH0ZsfWCdFVe1wj0XVfYI1qORekOr2SLTP2WF3wKkoIeWpi3dvStG/ wZDL91xSSJTICgAhcf1CcTEIzTO6p4h4XoreDwQzrsOcMB6MR4pdkrd5DO89AXAAecpp eJGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lightnvm-io.20150623.gappssmtp.com header.s=20150623 header.b=t94ENcsv; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g1si2246757pgv.186.2018.04.17.04.49.48; Tue, 17 Apr 2018 04:50:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@lightnvm-io.20150623.gappssmtp.com header.s=20150623 header.b=t94ENcsv; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752774AbeDQLs3 (ORCPT + 99 others); Tue, 17 Apr 2018 07:48:29 -0400 Received: from mail-pl0-f65.google.com ([209.85.160.65]:46272 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752357AbeDQLs1 (ORCPT ); Tue, 17 Apr 2018 07:48:27 -0400 Received: by mail-pl0-f65.google.com with SMTP id 59-v6so11832829plc.13 for ; Tue, 17 Apr 2018 04:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightnvm-io.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Hq+GnHOCuDzAwyPGxeqA+/ZegYzR3Z/XkaPxP3Zezdk=; b=t94ENcsvY4l6R4ZL3KxJEFxGtRQYqrA39gK8cp7G4/GMfi9O53bIFMjmbW7ZFWqc35 L2LlULFcwuDlUjfGK8yQXFxReFzd+ueQa/BEpXJCfmIsMaCCybTqsmLe2ufkmnhbX3oz TW0cljZk4ASxKpKEAubh8p3IbcjGhNRJETT6ZGwoyrN95l4lWWnXW1gEdZMq5EUJEctd RUpDkKIZS5T1jhn0sskYLssVcfcS+G5PCpZOUocJjkOD4X7FzJAzk3mdkgYuLQD/akK2 izcz3Yod4WLv0H/8emGi3tv9n8CzWilmipS8ekyZHZMi3bRCycTcxO1aYDJ8OMy3+BpQ OR1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Hq+GnHOCuDzAwyPGxeqA+/ZegYzR3Z/XkaPxP3Zezdk=; b=HMR/lpz2IRMN6wwylnbP9yCh5aVv+/Xhd5WiIL4mX2C0BmQdZQ2szM0EHbdxoFALOD RX00iwW8JkmVn+WdQzP0xDK1j6igzL4aumyRGyT41sNYHY7Q9GUKYZ1bHbxWyW5SpDko evo01Qupx5/TZM9zA/t7Tyo5aEQhmqSon/VPwfiXzLu90woTo/Jy8Ti+Corh6FaNnTLB 9BSsvnbtd81qZ2+d4agW3Al7e2JVMK0aGZDxMGRYiXwy/ozWloMnJNY+1aG01+hSZFPN C526hIWEDJ8fMDjcioxYJ0DmlmXmsfnGe+Gm4uTSFndtYp44PyxyQGJZNuz1Ffq4TIsd 7oyQ== X-Gm-Message-State: ALQs6tDwhnWX2peHCHDpEWuoB9c6FcXqJS0DWG03d2DgK6w0HC+IXllm CHJgvAXYI6lplIHhNsSL/40gLA== X-Received: by 2002:a17:902:4464:: with SMTP id k91-v6mr1693519pld.219.1523965706773; Tue, 17 Apr 2018 04:48:26 -0700 (PDT) Received: from C02VV2HXHV2Q.local ([104.153.224.169]) by smtp.gmail.com with ESMTPSA id m6sm5945012pgu.51.2018.04.17.04.48.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Apr 2018 04:48:25 -0700 (PDT) Subject: Re: [PATCH] lightnvm: pblk: take bitmap alloc. out of critical section To: =?UTF-8?Q?Javier_Gonz=c3=a1lez?= Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, =?UTF-8?Q?Javier_Gonz=c3=a1lez?= References: <1523874066-4459-1-git-send-email-javier@cnexlabs.com> From: =?UTF-8?Q?Matias_Bj=c3=b8rling?= Message-ID: <76bed955-2e70-7540-0836-f93fbd677d7e@lightnvm.io> Date: Tue, 17 Apr 2018 13:48:11 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1523874066-4459-1-git-send-email-javier@cnexlabs.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/16/18 12:21 PM, Javier González wrote: > Allocate line bitmaps outside of the line lock on line preparation. > > Signed-off-by: Javier González The patch description tells what the patch does, it should tell why the change the done. > --- > drivers/lightnvm/pblk-core.c | 96 +++++++++++++++++++++++++------------------- > 1 file changed, 55 insertions(+), 41 deletions(-) > > diff --git a/drivers/lightnvm/pblk-core.c b/drivers/lightnvm/pblk-core.c > index 5f960a6609c8..7762e89984ee 100644 > --- a/drivers/lightnvm/pblk-core.c > +++ b/drivers/lightnvm/pblk-core.c > @@ -1058,6 +1058,25 @@ static int pblk_line_init_metadata(struct pblk *pblk, struct pblk_line *line, > return 1; > } > > +static int pblk_line_alloc_bitmaps(struct pblk *pblk, struct pblk_line *line) > +{ > + struct pblk_line_meta *lm = &pblk->lm; > + > + line->map_bitmap = kzalloc(lm->sec_bitmap_len, GFP_KERNEL); > + if (!line->map_bitmap) > + return -ENOMEM; > + > + /* will be initialized using bb info from map_bitmap */ > + line->invalid_bitmap = kmalloc(lm->sec_bitmap_len, GFP_KERNEL); > + if (!line->invalid_bitmap) { > + kfree(line->map_bitmap); > + line->map_bitmap = NULL; > + return -ENOMEM; > + } > + > + return 0; > +} > + > /* For now lines are always assumed full lines. Thus, smeta former and current > * lun bitmaps are omitted. > */ > @@ -1162,18 +1181,7 @@ static int pblk_line_prepare(struct pblk *pblk, struct pblk_line *line) > { > struct pblk_line_meta *lm = &pblk->lm; > int blk_in_line = atomic_read(&line->blk_in_line); > - int blk_to_erase, ret; > - > - line->map_bitmap = kzalloc(lm->sec_bitmap_len, GFP_ATOMIC); > - if (!line->map_bitmap) > - return -ENOMEM; > - > - /* will be initialized using bb info from map_bitmap */ > - line->invalid_bitmap = kmalloc(lm->sec_bitmap_len, GFP_ATOMIC); > - if (!line->invalid_bitmap) { > - ret = -ENOMEM; > - goto fail_free_map_bitmap; > - } > + int blk_to_erase; > > /* Bad blocks do not need to be erased */ > bitmap_copy(line->erase_bitmap, line->blk_bitmap, lm->blk_per_line); > @@ -1191,15 +1199,15 @@ static int pblk_line_prepare(struct pblk *pblk, struct pblk_line *line) > } > > if (blk_in_line < lm->min_blk_line) { > - ret = -EAGAIN; > - goto fail_free_invalid_bitmap; > + spin_unlock(&line->lock); > + return -EAGAIN; > } > > if (line->state != PBLK_LINESTATE_FREE) { > WARN(1, "pblk: corrupted line %d, state %d\n", > line->id, line->state); > - ret = -EINTR; > - goto fail_free_invalid_bitmap; > + spin_unlock(&line->lock); > + return -EINTR; > } > > line->state = PBLK_LINESTATE_OPEN; > @@ -1213,16 +1221,6 @@ static int pblk_line_prepare(struct pblk *pblk, struct pblk_line *line) > kref_init(&line->ref); > > return 0; > - > -fail_free_invalid_bitmap: > - spin_unlock(&line->lock); > - kfree(line->invalid_bitmap); > - line->invalid_bitmap = NULL; > -fail_free_map_bitmap: > - kfree(line->map_bitmap); > - line->map_bitmap = NULL; > - > - return ret; > } > > int pblk_line_recov_alloc(struct pblk *pblk, struct pblk_line *line) > @@ -1242,13 +1240,15 @@ int pblk_line_recov_alloc(struct pblk *pblk, struct pblk_line *line) > } > spin_unlock(&l_mg->free_lock); > > - pblk_rl_free_lines_dec(&pblk->rl, line, true); > + if (pblk_line_alloc_bitmaps(pblk, line)) > + return -EINTR; Why return -EINTR, instead of the return value from (0, -ENOMEM) from pblk_line_alloc_bitmap? > > if (!pblk_line_init_bb(pblk, line, 0)) { > list_add(&line->list, &l_mg->free_list); > return -EINTR; > } > > + pblk_rl_free_lines_dec(&pblk->rl, line, true); > return 0; > } > > @@ -1260,6 +1260,24 @@ void pblk_line_recov_close(struct pblk *pblk, struct pblk_line *line) > line->emeta = NULL; > } > > +static void pblk_line_clear(struct pblk_line *line) > +{ > + *line->vsc = cpu_to_le32(EMPTY_ENTRY); > + > + line->map_bitmap = NULL; > + line->invalid_bitmap = NULL; > + line->smeta = NULL; > + line->emeta = NULL; > +} Instead of pblk_line_clear, how about pblk_line_reinit?