From: xiaochuan-xu <xiaochuan-xu@cqu.edu.cn>
To: Artem Bityutskiy <dedekind@infradead.org>
Cc: linux-mtd <linux-mtd@lists.infradead.org>
Subject: Deep thinking about the Wear-leveling mothed
Date: Tue, 29 Jul 2008 18:31:19 +0800 [thread overview]
Message-ID: <417327189.03021@cqu.edu.cn> (raw)
Message-ID: <1217327479.2812.24.camel@localhost.localdomain> (raw)
Hello,
most of current wear-leveling motheds are based on three ideas:
1. old-young eraseblocks swapping: If the difference between the erasure
cycles of a old block and a young block is larger then the STATIC
threshold, data stored in the old block and in the young block are
swqpped. this is the KEY idea.
2. young eraseblock priority selection and oldest eraseblock protection.
3. Hot-cold date separation.
I'd tried to improve the wear-leveling performanct by means of the
second and the third ideas improvment.
But unfortunately, the experimental resultes is not every exciting.
Why???? Maybe the current implementation is good enough or the last two
ideas are not the KEY.
Is it impossible to improve the current wear-leveling policy? NO!!!
Some important things, I think, should be clarify:
1. How to evaluate a wear-leveling method? there are, I consider, two
performance index:
@ the percentage of erasure counter triggered by wear-leveling in the
total erasure counter, refer to as wl_ec/total_ec here.
@ the difference between the oldest PEB and the youngest PEB (ECmax -
ECmin)
we can say that a wear-leveling algorithm is good if wl_ec/total_ec and
(ECmax - ECmin) are both small.
But unfortunately, it's defficult to minimize both wl_ec/total_ec and
(ECmax - ECmin) AT THE SAME TIME, because the wl_ec/total_ec is in
inverse proportion to the THRESHOLD, whereas the later is in direct
proportion to the THRESHOLD.
2. Do we really need wear-leveling when the oldest PEB is far from the
upper limit of reliable erasure?
the answer is NO!
we just need to ensure that no one ersaeblock reaches the limit long
before the rest of the chip. IOW, there is nearly no need to ensure the
(ECmax - ECmin) small enough when the ECmax is far from the limit.
So, we should pay more attention to reduce the wl_ec/total_ec before
the oldest PEB closes to the limit. It follows that the THRESHOLD should
be set large enough in the beginning. And then, when some PEB is close
to the limit, the THRESHOLD should small enough in order to evenly worn.
sum up, a DYNAMIC threshold is need.
--
yours Sincerely,
xiaochuan-xu (许小川)
next reply other threads:[~2008-07-29 10:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1217327479.2812.24.camel@localhost.localdomain>
2008-07-29 10:31 ` xiaochuan-xu [this message]
2008-07-30 6:22 ` Deep thinking about the Wear-leveling mothed Artem Bityutskiy
[not found] ` <1217409842.2786.1.camel@localhost.localdomain>
2008-07-30 9:24 ` xiaochuan-xu
2008-07-31 0:02 ` Iwo Mergler
2008-07-30 10:25 ` Artem Bityutskiy
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=417327189.03021@cqu.edu.cn \
--to=xiaochuan-xu@cqu.edu.cn \
--cc=dedekind@infradead.org \
--cc=linux-mtd@lists.infradead.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