Received: by 10.223.176.5 with SMTP id f5csp516305wra; Tue, 6 Feb 2018 02:58:33 -0800 (PST) X-Google-Smtp-Source: AH8x224goF1Y9qRLNtvZTO9zn66VBMePI9MMq65pMRHFcKg13cXJyWnqCsQ9Igm7dOoFePg87oSY X-Received: by 2002:a17:902:3225:: with SMTP id y34-v6mr1978020plb.399.1517914713320; Tue, 06 Feb 2018 02:58:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517914713; cv=none; d=google.com; s=arc-20160816; b=aXLuP4I64BVv8auV8aOi/arUWrWE4YSAjAPA9E3SLS7Et5il6Y7wDGbjfA118aQmgY K+c2OmfnfW+eD9ne5lKL6wjBqKxpFP9x0++hN5gzu18gQfF9OERIDbWqCqhLzUek1V7i brpSq5XdEAl4LqbX6ARHzMezWazlM7KRUqhi6hu82xWyJD3Zvq7gyszxGpXHEYIvHXEM YstNZ1t/R48SHjfFWBwvlBUtBGZM6dvQBv3ralZEGwwqN6wRw/Vef2xp+1kFQqUI7QXf /AJYw+q9PybaYgPQpz/5b3oqbpyXo+R7/JYiuXZ+dGN8sp2J29cpnpvnW/jDQcawurj0 Yjfw== 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=4Z+CDAWiT4GvUOV3ZtUrEqo+1ZiBYDwr26NcZbW5Dzk=; b=RbQz0tMlOovQh7lhPOgJC+0w1yTk8CShKRiCAlXf+uyFnYcstd8b+fDCqZXpZ6fIM3 eEmskFBkFjZrZD+INDvhRkO1/h9nA9GwtL8mRqOXyqZ3h4Hz0mh1sIe17B+bMblGl9Nj 5uk9JdyFXhJleBPPe8u4W7XDrxOtqfWrFCwwVaxmtojkLtNjzOK5d0CFKC0dX5gpqMO+ LTasTFKsOesT+TVx1ybmYwpBQagq8MFrdFHU5kyXyauBqa3idouGj5fN41L8+h220JCy 5/4K5Nb0cqkWc2N8DIwqRZaBf7LO8mWzCuQG0rWKgolgSi6kgUNyhiENtOgzFkGRHJnl VYAA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lightnvm-io.20150623.gappssmtp.com header.s=20150623 header.b=PGxDwMaj; 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 v10si3355951pgf.214.2018.02.06.02.58.19; Tue, 06 Feb 2018 02:58:33 -0800 (PST) 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=PGxDwMaj; 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 S1752689AbeBFK5E (ORCPT + 99 others); Tue, 6 Feb 2018 05:57:04 -0500 Received: from mail-lf0-f68.google.com ([209.85.215.68]:42256 "EHLO mail-lf0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752524AbeBFK47 (ORCPT ); Tue, 6 Feb 2018 05:56:59 -0500 Received: by mail-lf0-f68.google.com with SMTP id q17so2082908lfa.9 for ; Tue, 06 Feb 2018 02:56:58 -0800 (PST) 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=4Z+CDAWiT4GvUOV3ZtUrEqo+1ZiBYDwr26NcZbW5Dzk=; b=PGxDwMajBPYNKgKORsY9n61kdvY7rhWWy3Spw5KZIu66JGhw4ilIwndfAlGtJUxu2f p+iDjEyTJzppTLvfb8LnIsnnL/hoSpd/kQArPRWORs9EMHqD/j6SyXm4XytetASi+osb Uugs4bA3K+OFHPs39aq/kkOlYfwRITuw20+Xh2Chu2mZOLW85Jz5fU6dQwDaz7XywwI3 2zp6dQ4lA4RSa/CJJDFUHyHX7H7lwg0HzKSyFt5aIHbZUbT+5ZCs3FMmX/JZ4a2B5Rm7 3+J39ojBdf4jUK9eMTXmyP26o3wQ020bHbGFXf8l4O15xAwkRHQ03prYU1SuIOJh1RAr 5qMQ== 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=4Z+CDAWiT4GvUOV3ZtUrEqo+1ZiBYDwr26NcZbW5Dzk=; b=M4IfiDG6vhe5trf0HlEWhkIEzu79mFeyD2cjQlFnLqufHFAGxPisx3YQd3umlTQubS pJHWQYqyLhVXNiKeMtuDDgUWxO/CTwLXdRISwNUl2Akw8ODcfvWdpc7e2L9fnnG9ud24 Lq8lOq32hZyGeoHiFouXoFVgRmhnl2yu4S9HQsQlDgKcedXVOVeI1tgpdqk4fWpiyijf cwC6j2nqBYhAjwelzyAZfNuNJ75QGcrbNA+cCaG+AY43qaooGvD2qjZ7li9KiBWYm2zE v7IMT9amwOlk/UkSfmfQ58HCdPqS/TpKNB72HHTKQrYNzy1M7VmX+8KTYJGlBju7dp9D zAeA== X-Gm-Message-State: APf1xPBoytPZUnXIuulXnL8PxaZ8dIefgb4gq6JA9R+lxc2LAsN2Mp0B cltt300Zc5fy+kvVSJazAvXJLw== X-Received: by 10.25.20.31 with SMTP id k31mr1414878lfi.87.1517914229117; Tue, 06 Feb 2018 02:50:29 -0800 (PST) Received: from [192.168.0.10] (x1-6-a4-08-f5-18-3c-3a.cpe.webspeed.dk. [188.176.29.198]) by smtp.googlemail.com with ESMTPSA id g68sm2313885lfi.42.2018.02.06.02.50.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Feb 2018 02:50:28 -0800 (PST) Subject: Re: [PATCH 4/5] lightnvm: pblk: add padding distribution sysfs attribute To: Hans Holmberg Cc: =?UTF-8?Q?Javier_Gonz=c3=a1lez?= , linux-block@vger.kernel.org, Linux Kernel Mailing List , Hans Holmberg , =?UTF-8?Q?Javier_Gonz=c3=a1lez?= References: <1517364411-22386-1-git-send-email-javier@cnexlabs.com> <1517364411-22386-4-git-send-email-javier@cnexlabs.com> From: =?UTF-8?Q?Matias_Bj=c3=b8rling?= Message-ID: <3aaf482e-0f4f-9001-8df1-1ccd2004ce02@lightnvm.io> Date: Tue, 6 Feb 2018 11:50:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/06/2018 10:27 AM, Hans Holmberg wrote: > Hi Matias, > > On Wed, Jan 31, 2018 at 9:44 AM, Matias Bjørling wrote: >> On 01/31/2018 03:06 AM, Javier González wrote: >>> >>> From: Hans Holmberg >>> >>> When pblk receives a sync, all data up to that point in the write buffer >>> must be comitted to persistent storage, and as flash memory comes with a >>> minimal write size there is a significant cost involved both in terms >>> of time for completing the sync and in terms of write amplification >>> padded sectors for filling up to the minimal write size. >>> >>> In order to get a better understanding of the costs involved for syncs, >>> Add a sysfs attribute to pblk: padded_dist, showing a normalized >>> distribution of sectors padded. In order to facilitate measurements of >>> specific workloads during the lifetime of the pblk instance, the >>> distribution can be reset by writing 0 to the attribute. >>> >>> Do this by introducing counters for each possible padding: >>> {0..(minimal write size - 1)} and calculate the normalized distribution >>> when showing the attribute. >>> >>> Signed-off-by: Hans Holmberg >>> Signed-off-by: Javier González >>> --- >>> drivers/lightnvm/pblk-init.c | 16 ++++++++-- >>> drivers/lightnvm/pblk-rb.c | 15 +++++----- >>> drivers/lightnvm/pblk-sysfs.c | 68 >>> +++++++++++++++++++++++++++++++++++++++++++ >>> drivers/lightnvm/pblk.h | 6 +++- >>> 4 files changed, 95 insertions(+), 10 deletions(-) >>> >>> diff --git a/drivers/lightnvm/pblk-init.c b/drivers/lightnvm/pblk-init.c >>> index 7eedc5daebc8..a5e3510c0f38 100644 >>> --- a/drivers/lightnvm/pblk-init.c >>> +++ b/drivers/lightnvm/pblk-init.c >>> @@ -921,6 +921,7 @@ static void pblk_free(struct pblk *pblk) >>> { >>> pblk_luns_free(pblk); >>> pblk_lines_free(pblk); >>> + kfree(pblk->pad_dist); >>> pblk_line_meta_free(pblk); >>> pblk_core_free(pblk); >>> pblk_l2p_free(pblk); >>> @@ -998,11 +999,13 @@ static void *pblk_init(struct nvm_tgt_dev *dev, >>> struct gendisk *tdisk, >>> pblk->pad_rst_wa = 0; >>> pblk->gc_rst_wa = 0; >>> + atomic_long_set(&pblk->nr_flush, 0); >>> + pblk->nr_flush_rst = 0; >>> + >>> #ifdef CONFIG_NVM_DEBUG >>> atomic_long_set(&pblk->inflight_writes, 0); >>> atomic_long_set(&pblk->padded_writes, 0); >>> atomic_long_set(&pblk->padded_wb, 0); >>> - atomic_long_set(&pblk->nr_flush, 0); >>> atomic_long_set(&pblk->req_writes, 0); >>> atomic_long_set(&pblk->sub_writes, 0); >>> atomic_long_set(&pblk->sync_writes, 0); >>> @@ -1034,10 +1037,17 @@ static void *pblk_init(struct nvm_tgt_dev *dev, >>> struct gendisk *tdisk, >>> goto fail_free_luns; >>> } >>> + pblk->pad_dist = kzalloc((pblk->min_write_pgs - 1) * >>> sizeof(atomic64_t), >>> + GFP_KERNEL); >>> + if (!pblk->pad_dist) { >>> + ret = -ENOMEM; >>> + goto fail_free_line_meta; >>> + } >>> + >>> ret = pblk_core_init(pblk); >>> if (ret) { >>> pr_err("pblk: could not initialize core\n"); >>> - goto fail_free_line_meta; >>> + goto fail_free_pad_dist; >>> } >>> ret = pblk_l2p_init(pblk); >>> @@ -1097,6 +1107,8 @@ static void *pblk_init(struct nvm_tgt_dev *dev, >>> struct gendisk *tdisk, >>> pblk_l2p_free(pblk); >>> fail_free_core: >>> pblk_core_free(pblk); >>> +fail_free_pad_dist: >>> + kfree(pblk->pad_dist); >>> fail_free_line_meta: >>> pblk_line_meta_free(pblk); >>> fail_free_luns: >>> diff --git a/drivers/lightnvm/pblk-rb.c b/drivers/lightnvm/pblk-rb.c >>> index 7044b5599cc4..264372d7b537 100644 >>> --- a/drivers/lightnvm/pblk-rb.c >>> +++ b/drivers/lightnvm/pblk-rb.c >>> @@ -437,9 +437,7 @@ static int pblk_rb_may_write_flush(struct pblk_rb *rb, >>> unsigned int nr_entries, >>> if (bio->bi_opf & REQ_PREFLUSH) { >>> struct pblk *pblk = container_of(rb, struct pblk, rwb); >>> -#ifdef CONFIG_NVM_DEBUG >>> atomic_long_inc(&pblk->nr_flush); >>> -#endif >>> if (pblk_rb_flush_point_set(&pblk->rwb, bio, mem)) >>> *io_ret = NVM_IO_OK; >>> } >>> @@ -620,14 +618,17 @@ unsigned int pblk_rb_read_to_bio(struct pblk_rb *rb, >>> struct nvm_rq *rqd, >>> pr_err("pblk: could not pad page in write bio\n"); >>> return NVM_IO_ERR; >>> } >>> + >>> + if (pad < pblk->min_write_pgs) >>> + atomic64_inc(&pblk->pad_dist[pad - 1]); >>> + else >>> + pr_warn("pblk: padding more than min. sectors\n"); >> >> >> Curious, when would this happen? Would it be an implementation error or >> something a user did wrong? > > This would be an implementation error - and this check is just a > safeguard to make sure we won't go out of bounds when updating the > statistics. > Ah, does it make sense to have such defensive programming, when the value is never persisted? An 64 bit integer is quite large, and if only used for workloads for a single instance, it would practically never trigger, and if it did, do one care? >> >> Looks good to me. Let me know if you want to send a new patch, or if I may >> make the change when I pick it up. > > Thanks for the review, i saw that you already reworked the patch a bit > on your core branch. > However, i found a build issue when building for i386, so i'll fix > that and submit a V2(that includes your update) Ok. I assume this is the kbuild mail I asked about a couple of days ago. I'll wait for v2.