Deep thinking about the Wear-leveling mothed

Deep thinking about the Wear-leveling mothed

[xiaochuan-xu]

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 (许小川)

Re: Deep thinking about the Wear-leveling mothed

[Artem Bityutskiy]

Hi,

On Tue, 2008-07-29 at 18:31 +0800, xiaochuan-xu wrote:
> 2. Do we really need wear-leveling when the oldest PEB is far from the
> upper limit of reliable erasure? 
>    the answer is NO! 

I would not be so sure. When UBI looses an erase counter because of an
unclean reboot, it assigns average erase counter to that eraseblock.
This works fine because UBI maintains a reasonably small Max-Min
difference.

Also, I am not sure it is save to erase one eraseblock several million
times and do not erase neighbor eraseblocks. There are "radiation"
effects in some flashes, when unused eraseblocks slowly "rot" when their
neighbor eraseblocks are used a lot.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

Re: Deep thinking about the Wear-leveling mothed

[xiaochuan-xu]

On Wed, 2008-07-30 at 09:22 +0300, Artem Bityutskiy wrote:
> Also, I am not sure it is save to erase one eraseblock several million
> times and do not erase neighbor eraseblocks. There are "radiation"
> effects in some flashes, when unused eraseblocks slowly "rot" when
> their
> neighbor eraseblocks are used a lot.

I'm sorry but I'm not understand this clearly.


-- 
yours Sincerely,

xiaochuan-xu (许小川)

Re: Deep thinking about the Wear-leveling mothed

[Iwo Mergler]

xiaochuan-xu wrote:
> On Wed, 2008-07-30 at 09:22 +0300, Artem Bityutskiy wrote:
>> Also, I am not sure it is save to erase one eraseblock several million
>> times and do not erase neighbor eraseblocks. There are "radiation"
>> effects in some flashes, when unused eraseblocks slowly "rot" when
>> their
>> neighbor eraseblocks are used a lot.
> 
> I'm sorry but I'm not understand this clearly.
> 
> 

You might be aware of the fact that after erasure of NAND FLASH,
you are only allowed to write a page once (or a small number of times).

In principle, the write operation is like a logical AND between
the new page content and the old one. That is, writing '0' will
result in a '0', writing a '1' leaves the bit unchanged.

However, in this context, you must regard NAND cells as analog devices.
What you store is not numbers, but electric charge. Erasing the cells
drains the charge (='1'), writing a '0' increases the charge. A charge
above a certain threshold is read as '0', below that is read as '1'.

Due to the proximity of the NAND cells, there is some leakage between
them. Writing a '0' into a cell leaks a little charge into the neighbouring
cells. Also, writing a '1' is not quite perfect and also moves a cell
a notch towards '0'. In other words, memory contents deteriorate despite
'correct' digital operations.

The manufacturers put more effort (and silicon area) into separating
individual erase blocks than into separating individual pages than into
separating individual bits.

But nothing is perfect. Writing a page has a small effect on bits in
neighbouring pages and even in neighbouring erase blocks.

This, I think, is what Artem meant. Although it's 'leakage' rather
than 'radiation'. :-)

Kind regards,

Iwo

Re: Deep thinking about the Wear-leveling mothed

[Artem Bityutskiy]

On Wed, 2008-07-30 at 17:24 +0800, xiaochuan-xu wrote:
> On Wed, 2008-07-30 at 09:22 +0300, Artem Bityutskiy wrote:
> > Also, I am not sure it is save to erase one eraseblock several million
> > times and do not erase neighbor eraseblocks. There are "radiation"
> > effects in some flashes, when unused eraseblocks slowly "rot" when
> > their
> > neighbor eraseblocks are used a lot.
> 
> I'm sorry but I'm not understand this clearly.

In this particular case I meant AG-AND flashes. They had "radiation"
effect, which means if you have 2 eraseblocks A and B, and you change A
a lot, but do not change B, B may become corrupted at some point.

P.S. I have not idea if these flashes are still produced/used.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)