Re: [PATCH] [RFC] UBI: Implement Fastmap support

From: Richard Weinberger
Date: Thu May 24 2012 - 06:03:28 EST


On 24.05.2012 11:56, Shmulik Ladkani wrote:
Hi Artem,

On Thu, 24 May 2012 11:17:52 +0300 Artem Bityutskiy<dedekind1@xxxxxxxxx> wrote:
On Tue, 2012-05-22 at 18:55 +0200, Richard Weinberger wrote:
+ e = find_early_wl_entry(&ubi->free, max_pnum);

This picks the eb with the lowest pnum within 'ubi->free'.

When called with INT_MAX (for the FM_DATA), why do you need to pick
a
free eb with the minimal pnum? The FM_DATA EBs may reside everywhere
(as
the FM_SB holds their location).
So why not pick the eb with a medium EC value (as done for standard
get_peb calls)? That might be better wear-leveling wise.

Fair point.
I'll fix that.
Artem, any comments on that?

The 'find_early_wl_entry()' function is used (currently) only at early
stages. At these stages the we do not have the PEBs sorted by EC. We
have just a list. This function should not be use after the WL subsystem
is initialized.

'find_early_wl_entry' is only called from 'ubi_wl_get_fm_peb'.

Correct.

'ubi_wl_get_fm_peb' is called twice from within 'ubi_update_fastmap':
First call, to get the FM_SB, with 'max_pnum' set as UBI_FM_MAX_START.
Second, to get FM_DATA pebs, with 'max_pnum' as -1, do indicate "no
matter the location, give me pebs from the free pool".

Correct. Maybe I should rename find_early_wl_entry() to find_wl_entry_for_fastmap() or something like that...

'ubi_update_fastmap' is called from 'ubi_volume_notify' and from
'ubi_wl_get_peb' - at both points, I assume ubi->free rbtree is properly
populated. Am I mistaken?

Also correct.

Thanks,
//richard

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/