From: Artem Bityutskiy <dedekind1@gmail.com>
To: Tanya Brokhman <tlinder@codeaurora.org>
Cc: dedeking1@gmail.com, linux-mtd@lists.infradead.org,
linux-arm-msm@vger.kernel.org,
David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
Richard Weinberger <richard@nod.at>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC/PATCH 1/5] mtd: ubi: Read disturb infrastructure
Date: Sun, 28 Sep 2014 15:11:16 +0300 [thread overview]
Message-ID: <1411906276.11836.21.camel@karhu> (raw)
In-Reply-To: <1411886220-8208-1-git-send-email-tlinder@codeaurora.org>
On Sun, 2014-09-28 at 09:37 +0300, Tanya Brokhman wrote:
> The need for performing read disturb is determined according to new
> statistics collected per eraseblock:
> - read counter: incremented at each read operation
> reset at each erase
> - last erase time stamp: updated at each erase
>
> This patch adds the infrastructure for the above statistics
Would you please provide some kind of high level description for this
stuff. What is the problem at hand, how is it solved. Right off-the top
of my head I have the following comment.
Adding more fields to 'struct ubi_wl_entry' should be well-justified.
These objects are per-PEB, so there may be really a lot of them, and
they may consume a lot of memory. Increasing the size of the object may
be affect the memory consumption a lot.
So I wonder if these read counters solve a big enough problem, so that
they are worth having in this data structure.
So I am really missing the bigger picture here.
--
Best Regards,
Artem Bityutskiy
next prev parent reply other threads:[~2014-09-28 12:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-28 6:37 [RFC/PATCH 1/5] mtd: ubi: Read disturb infrastructure Tanya Brokhman
2014-09-28 8:18 ` Richard Weinberger
2014-09-28 8:48 ` Tanya Brokhman
2014-09-28 8:54 ` Richard Weinberger
2014-09-28 10:46 ` Tanya Brokhman
2014-09-28 10:54 ` Richard Weinberger
2014-10-02 12:50 ` Tanya Brokhman
2014-10-02 13:24 ` Richard Weinberger
2014-10-02 13:42 ` Tanya Brokhman
2014-10-02 14:05 ` Richard Weinberger
2014-10-03 15:38 ` Artem Bityutskiy
2014-10-07 13:55 ` Richard Weinberger
2014-10-02 13:36 ` Richard Weinberger
2014-10-02 14:11 ` Tanya Brokhman
2014-09-28 12:11 ` Artem Bityutskiy [this message]
2014-09-28 14:54 ` Tanya Brokhman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1411906276.11836.21.camel@karhu \
--to=dedekind1@gmail.com \
--cc=computersforpeace@gmail.com \
--cc=dedeking1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=tlinder@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).