From patchwork Mon Oct 2 11:27:42 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?UTF-8?q?Javier=20Gonz=C3=A1lez?= X-Patchwork-Id: 9980703 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id A394460384 for ; Mon, 2 Oct 2017 11:27:48 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 95B1B285D3 for ; Mon, 2 Oct 2017 11:27:48 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8A6A6288C5; Mon, 2 Oct 2017 11:27:48 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7F448285D3 for ; Mon, 2 Oct 2017 11:27:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751174AbdJBL1q (ORCPT ); Mon, 2 Oct 2017 07:27:46 -0400 Received: from mail-wm0-f44.google.com ([74.125.82.44]:54498 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751179AbdJBL1q (ORCPT ); Mon, 2 Oct 2017 07:27:46 -0400 Received: by mail-wm0-f44.google.com with SMTP id i124so9897811wmf.3 for ; Mon, 02 Oct 2017 04:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightnvm-io.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=QPu0QESw/XyupZa3fDG3TmkwZIHzKYcKfrAA6RIyBKc=; b=O9hJyyJvvzdKZ9xV528b+VpPbwK1ApBMO89M2rTkF3zCRqTrOduW0lpAVaCaj/C4Ep WJjKiLh3E3XcuOjfxaCuzKG0IQYHd653uPPdS3dN6QNM8kB4yDOjuEiMJRBWUb20hjxc r8dVNLppvD8zARpVPn9bZlYXN7P4eFJdGDaa7QT1eJRQnSpgB5vFtHWfEPm+qn8rypsy WgNWXEQwRihTi4yFobqD2fPV9aIxsqHkUHeVNujuMQKDOQar8hMOHH4CDpbPCd9NLZg4 Jtu7W25hS3bY6xJM8n/3lnn6gzY6VA6Ju4WMeKvKJrti+cjBjiVB1XjXjsCPJzHiJWi1 80KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=QPu0QESw/XyupZa3fDG3TmkwZIHzKYcKfrAA6RIyBKc=; b=q3JT0G8pUGw/DYwz4KvacD+o7j9UFSAarCeI03U+yjDtdbrammXxjvZGG1djK+x+nB AoOIwBKCIIUey9MstlV9clEVKQlrVAlXzpgsu2vhrjPk3Ifg7LAt4n0aLcpI1IaM/BeN +eIjAXDLgYjNjClR7HxEYgcptZ5qLSRo6XLtPlLRyvcF85DewKagPQ21zx8OqQ70/Eoy gW8hegX/JsKPbFjBL+DJNb/q51d8xKrRk9hx2Roy//tuJR4HAdpvFjhp0YF/gqd3soPt q1W4XoYMxtUBcEtESUG8GIgbBekJdfuG8KVYW98IueBhmC9BvyS8qjFGWIu+cM7wmY7+ qCXA== X-Gm-Message-State: AHPjjUi3pjjN/488N+sdD8PNe+T/+Bv8ZPLBaJL4UPmoev0FruSpZuBb CiCB2nZxhdMSFWYqSU1eeF37xg== X-Google-Smtp-Source: AOwi7QB5VNv0Rt2WpivbPc8z0HLLTe1tVIc66WTw3EqOUH8M0RKs29KflbhmkwNBWTA58+glKrUfGA== X-Received: by 10.80.157.141 with SMTP id w13mr20322309ede.151.1506943664501; Mon, 02 Oct 2017 04:27:44 -0700 (PDT) Received: from [172.31.0.41] (6164211-cl69.boa.fiberby.dk. [193.106.164.211]) by smtp.gmail.com with ESMTPSA id b36sm9935469edd.67.2017.10.02.04.27.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Oct 2017 04:27:43 -0700 (PDT) From: =?utf-8?Q?Javier_Gonz=C3=A1lez?= Message-Id: <5656C93D-F3DF-4054-906C-C27542D265CA@lightnvm.io> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH] lightnvm: pblk: fix changing GC group list for a line Date: Mon, 2 Oct 2017 13:27:42 +0200 In-Reply-To: <20170928143828.GA7645@hercules.tuxera.com> Cc: =?utf-8?Q?Matias_Bj=C3=B8rling?= , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org To: Rakesh Pandit References: <20170928143828.GA7645@hercules.tuxera.com> X-Mailer: Apple Mail (2.3273) Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP > On 28 Sep 2017, at 16.40, Rakesh Pandit wrote: > > pblk_line_gc_list seems to had a bug since the introduction of pblk in > getting GC list for a line. In b20ba1bc7 while redesigning GC > algorithm it was not fixed correctly. The problem is that even if > valid sector count (vsc) is less that mid_thrs (threshold for GC mid > list) it would always satisfy 'vsc < high_thrs' as high_thrs > > mid_thrs always. > > Fixes: a4bd217b4("lightnvm: physical block device (pblk) target") > Signed-off-by: Rakesh Pandit > --- > drivers/lightnvm/pblk-core.c | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/lightnvm/pblk-core.c b/drivers/lightnvm/pblk-core.c > index 8150164..93a58ed 100644 > --- a/drivers/lightnvm/pblk-core.c > +++ b/drivers/lightnvm/pblk-core.c > @@ -295,16 +295,16 @@ struct list_head *pblk_line_gc_list(struct pblk *pblk, struct pblk_line *line) > line->gc_group = PBLK_LINEGC_FULL; > move_list = &l_mg->gc_full_list; > } > - } else if (vsc < lm->high_thrs) { > - if (line->gc_group != PBLK_LINEGC_HIGH) { > - line->gc_group = PBLK_LINEGC_HIGH; > - move_list = &l_mg->gc_high_list; > - } > } else if (vsc < lm->mid_thrs) { > if (line->gc_group != PBLK_LINEGC_MID) { > line->gc_group = PBLK_LINEGC_MID; > move_list = &l_mg->gc_mid_list; > } > + } else if (vsc < lm->high_thrs) { > + if (line->gc_group != PBLK_LINEGC_HIGH) { > + line->gc_group = PBLK_LINEGC_HIGH; > + move_list = &l_mg->gc_high_list; > + } > } else if (vsc < line->sec_in_line) { > if (line->gc_group != PBLK_LINEGC_LOW) { > line->gc_group = PBLK_LINEGC_LOW; > -- > 2.9.3 You're right that the naming for high/mid/low was not updated when aligning vsc with GC thresholds. But the fix should be making high, being high, instead of reordering when moving into the GC bucket. Does it make sense to you? diff --git i/drivers/lightnvm/pblk-init.c w/drivers/lightnvm/pblk-init.c index 7cf4b536d899..bc5c6cc12ad5 100644 --- i/drivers/lightnvm/pblk-init.c +++ w/drivers/lightnvm/pblk-init.c @@ -675,8 +675,8 @@ static int pblk_lines_init(struct pblk *pblk) lm->blk_bitmap_len = BITS_TO_LONGS(geo->nr_luns) * sizeof(long); lm->sec_bitmap_len = BITS_TO_LONGS(lm->sec_per_line) * sizeof(long); lm->lun_bitmap_len = BITS_TO_LONGS(geo->nr_luns) * sizeof(long); - lm->high_thrs = lm->sec_per_line / 2; - lm->mid_thrs = lm->sec_per_line / 4; + lm->high_thrs = lm->sec_per_line / 4; + lm->mid_thrs = lm->sec_per_line / 2; lm->meta_distance = (geo->nr_luns / 2) * pblk->min_write_pgs; /* Calculate necessary pages for smeta. See comment over struct