From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
To: dedekind1@gmail.com
Cc: Richard Weinberger <richard@nod.at>,
linux-kernel@vger.kernel.org, Heinz.Egger@linutronix.de,
linux-mtd@lists.infradead.org, tim.bird@am.sony.com,
tglx@linutronix.de
Subject: Re: [PATCH] [RFC] UBI: Implement Fastmap support
Date: Thu, 24 May 2012 12:56:12 +0300 [thread overview]
Message-ID: <20120524125612.39d3e6aa@halley> (raw)
In-Reply-To: <1337847472.15137.81.camel@sauron.fi.intel.com>
Hi Artem,
On Thu, 24 May 2012 11:17:52 +0300 Artem Bityutskiy <dedekind1@gmail.com> 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'.
'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".
'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?
Regards,
Shmulik
WARNING: multiple messages have this Message-ID (diff)
From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
To: dedekind1@gmail.com
Cc: Richard Weinberger <richard@nod.at>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
Heinz.Egger@linutronix.de, tim.bird@am.sony.com,
tglx@linutronix.de
Subject: Re: [PATCH] [RFC] UBI: Implement Fastmap support
Date: Thu, 24 May 2012 12:56:12 +0300 [thread overview]
Message-ID: <20120524125612.39d3e6aa@halley> (raw)
In-Reply-To: <1337847472.15137.81.camel@sauron.fi.intel.com>
Hi Artem,
On Thu, 24 May 2012 11:17:52 +0300 Artem Bityutskiy <dedekind1@gmail.com> 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'.
'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".
'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?
Regards,
Shmulik
next prev parent reply other threads:[~2012-05-24 9:56 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-21 14:01 [RFC v6] UBI: Fastmap support (aka checkpointing) Richard Weinberger
2012-05-21 14:01 ` Richard Weinberger
2012-05-21 14:01 ` [PATCH] [RFC] UBI: Implement Fastmap support Richard Weinberger
2012-05-21 14:01 ` Richard Weinberger
2012-05-22 13:43 ` Artem Bityutskiy
2012-05-22 13:43 ` Artem Bityutskiy
2012-05-22 15:01 ` Shmulik Ladkani
2012-05-22 15:01 ` Shmulik Ladkani
2012-05-22 16:55 ` Richard Weinberger
2012-05-22 16:55 ` Richard Weinberger
2012-05-22 18:18 ` Shmulik Ladkani
2012-05-22 18:18 ` Shmulik Ladkani
2012-05-22 18:57 ` Richard Weinberger
2012-05-22 18:57 ` Richard Weinberger
2012-05-23 6:18 ` Shmulik Ladkani
2012-05-23 6:18 ` Shmulik Ladkani
2012-05-23 7:43 ` Richard Weinberger
2012-05-23 7:43 ` Richard Weinberger
2012-05-22 20:11 ` Richard Weinberger
2012-05-22 20:11 ` Richard Weinberger
2012-05-24 8:19 ` Artem Bityutskiy
2012-05-24 8:19 ` Artem Bityutskiy
2012-05-24 8:26 ` Richard Weinberger
2012-05-24 8:26 ` Richard Weinberger
2012-05-24 9:21 ` Artem Bityutskiy
2012-05-24 9:21 ` Artem Bityutskiy
2012-05-24 8:17 ` Artem Bityutskiy
2012-05-24 8:17 ` Artem Bityutskiy
2012-05-24 9:56 ` Shmulik Ladkani [this message]
2012-05-24 9:56 ` Shmulik Ladkani
2012-05-24 10:03 ` Richard Weinberger
2012-05-24 10:03 ` Richard Weinberger
2012-05-24 20:07 ` Shmulik Ladkani
2012-05-24 20:07 ` Shmulik Ladkani
2012-05-24 8:22 ` Artem Bityutskiy
2012-05-24 8:22 ` Artem Bityutskiy
2012-05-24 8:24 ` Richard Weinberger
2012-05-24 8:24 ` Richard Weinberger
-- strict thread matches above, loose matches on Subject: below --
2012-05-23 11:06 [RFC v7] UBI: Fastmap support (aka checkpointing) Richard Weinberger
2012-05-23 11:06 ` [PATCH] [RFC] UBI: Implement Fastmap support Richard Weinberger
2012-05-23 11:06 ` Richard Weinberger
2012-05-26 13:22 ` Artem Bityutskiy
2012-05-26 13:22 ` Artem Bityutskiy
2012-05-31 10:37 ` Adrian Hunter
2012-05-31 10:37 ` Adrian Hunter
2012-05-31 13:31 ` Richard Weinberger
2012-05-31 13:31 ` Richard Weinberger
2012-06-01 5:47 ` Adrian Hunter
2012-06-01 5:47 ` Adrian Hunter
2012-06-01 8:00 ` Richard Weinberger
2012-06-01 8:00 ` Richard Weinberger
2012-06-01 8:10 ` Artem Bityutskiy
2012-06-01 8:10 ` Artem Bityutskiy
2012-06-01 8:10 ` Richard Weinberger
2012-06-01 8:10 ` Richard Weinberger
2012-06-01 8:47 ` Adrian Hunter
2012-06-01 8:47 ` Adrian Hunter
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=20120524125612.39d3e6aa@halley \
--to=shmulik.ladkani@gmail.com \
--cc=Heinz.Egger@linutronix.de \
--cc=dedekind1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=tglx@linutronix.de \
--cc=tim.bird@am.sony.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.