ubi: why ubi wear leveling always pick highly worn-out free physical eraseblock

Ryder Wang rydercoding at hotmail.com
Fri Feb 23 02:14:21 PST 2024


Hi Zhihao,

Thanks for your reply.

You explained why e1 and e2 use picked to compare with CONFIG_MTD_UBI_WL_THRESHOLD to decide whether WL is needed. That's right as I also mentioned. However, the point is that why such high worn-out free physical eraseblock (in ubi->free tree) should be used to store the data of e1? High worn-out PEB should always be avoided to use (low worn-out PEB of ubi->free tree should be preferred), right?

________________________________________
From: Zhihao Cheng <chengzhihao1 at huawei.com>
Sent: Friday, February 23, 2024 15:11
To: Ryder Wang; linux-mtd at lists.infradead.org; richard at nod.at
Subject: Re: ubi: why ubi wear leveling always pick highly worn-out free physical eraseblock as the mov_to target

在 2024/2/23 11:27, Ryder Wang 写道:
> Refer to the ubi source code:
> wear_leveling_worker
>    e2 = get_peb_for_wl(ubi)
>      e = find_wl_entry(ubi, &ubi->free, WL_FREE_MAX_DIFF);
>
> The function find_wl_entry() always find the  highly worn-out free physical eraseblock (e2):
> 1. It's good to check such PEB (e2) to decide whether the following wear leveling procedure should be continued according to UBI_WL_THRESHOLD.
> 2. But personally I can't understand why such high worn-out free physical eraseblock should also be used as target PEB(move_to) to store the move_from data for wear leveling purpose. Will it be much more reasonable to use low worn-out free physical eraseblock (from ubi->free tree) in this case for more perfect wear leveling?.
>

Normally, e1 is the smaller ec counter picked from ubi->used, e2 is
bigger ec counter picked from ubi->free, the wear-leveling worker
follows that rule which is based on the realization of free PEBs fetching.
First, let's talk about the simplest case without fastmap, assumpt that
CONFIG_MTD_UBI_WL_THRESHOLD=2, there are total 3 PEBs.
Only 1 EB(erase block) is used, then free it, and repeat the process
forvever. According to the implementation in
ubi_wl_get_peb->wl_get_wle->find_mean_wl_entry, the ubi->free tree will
change like:
(1,1,1) -> (1,1,2) -> (1,2,2) -> (1,2,3) -> (1,3,3) -> ... -> (1,4,5) ->
(2,4,5), which means that wear-leveling worker is not needed, because
find_mean_wl_entry has made sure that 'max_ec - min_ec <= 2 *
CONFIG_MTD_UBI_WL_THRESHOLD'. Similar, when there are more EBs are used
and freed, there is no need to trigger wear-leveling work.
However, if one free PEB is taken and not be freed, other free PEBs are
taken and freed, like:
ubi->used: 1
ubi->free: (1, 1) -> (1, 2) -> ... (x, y)
After a while, min(x,y) - 1 will be greater than
2*CONFIG_MTD_UBI_WL_THRESHOLD. Then, wear-leveling should start working,
cold data always takes certain PEB for a long time, which causes PEBs
with smaller ec counter gather in ubi->used and PEBs with bigger ec
counter gather in ubi->freed.
I think that's the explainations of the rule how to pick e1/e2.



More information about the linux-mtd mailing list