From: Artem Bityutskiy <dedekind1@gmail.com>
To: Richard Weinberger <richard@nod.at>
Cc: richard.genoud@gmail.com, linux-mtd@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/7] UBI: fix refill_wl_user_pool()
Date: Thu, 03 Oct 2013 19:41:55 +0300 [thread overview]
Message-ID: <1380818515.18862.0.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <524D9CE1.8040600@nod.at>
On Thu, 2013-10-03 at 18:35 +0200, Richard Weinberger wrote:
> Am 03.10.2013 18:00, schrieb Artem Bityutskiy:
> > On Thu, 2013-10-03 at 17:53 +0200, Richard Weinberger wrote:
> >> Am 03.10.2013 17:27, schrieb Artem Bityutskiy:
> >>> On Thu, 2013-10-03 at 17:08 +0200, Richard Weinberger wrote:
> >>>> Am 03.10.2013 17:00, schrieb Artem Bityutskiy:
> >>>>> On Sat, 2013-09-28 at 15:55 +0200, Richard Weinberger wrote:
> >>>>>> If no free PEBs are available refill_wl_user_pool() must not
> >>>>>> return with -ENOSPC immediately.
> >>>>>> It has to block till produce_free_peb() produced a free PEB.
> >>>>>>
> >>>>>> Reported-and-Tested-by: Richard Genoud <richard.genoud@gmail.com>
> >>>>>> Signed-off-by: Richard Weinberger <richard@nod.at>
> >>>>>
> >>>>> What is pool size, I wonder?
> >>>>
> >>>> Currently it's 25 (UBI_FM_WL_POOL_SIZE).
> >>>> If experience shows that 25 is too low/big we can change this constant.
> >>>> Maybe it's also worth making them configurable...
> >>>
> >>> I if it is a possible scenario that this function will not return until
> >>> 25 (or even 10) PEBs are erased?
> >>>
> >>
> >> Sure. It will try to gain up to 25 PEBs but return if it gets less.
> >> That's why a pool has a current and a max size.
> >
> > So if erasing speed is say, 250ms, then it would take 6.25 seconds?
>
> Only in the very worst case if we have to call 25 times produce_free_peb().
>
> Of course we could add a check to return immediately if produce_free_peb()
> got called a few times in series.
> But I really would like to wait with such performance tweaks until fastmap
> is more mature.
OK, but how about at least adding a comment talking about this unlikely
scenario?
--
Best Regards,
Artem Bityutskiy
next prev parent reply other threads:[~2013-10-03 16:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-28 13:55 UBI fastmap updates Richard Weinberger
2013-09-28 13:55 ` [PATCH 1/7] UBI: fix refill_wl_user_pool() Richard Weinberger
2013-10-03 15:00 ` Artem Bityutskiy
2013-10-03 15:08 ` Richard Weinberger
2013-10-03 15:27 ` Artem Bityutskiy
2013-10-03 15:53 ` Richard Weinberger
2013-10-03 16:00 ` Artem Bityutskiy
2013-10-03 16:35 ` Richard Weinberger
2013-10-03 16:41 ` Artem Bityutskiy [this message]
2013-10-03 16:48 ` Richard Weinberger
2013-09-28 13:55 ` [PATCH 2/7] UBI: Fix error path in scan_pool() Richard Weinberger
2013-09-28 13:55 ` [PATCH 3/7] UBI: Call scan_all() with correct offset in error case Richard Weinberger
2013-09-28 13:55 ` [PATCH 4/7] UBI: fastmap: fix backward compatibility with image_seq Richard Weinberger
2013-09-28 13:55 ` [PATCH 5/7] UBI: simplify image sequence test Richard Weinberger
2013-09-28 13:55 ` [PATCH 6/7] UBI: Fix memory leak in ubi_attach_fastmap() error path Richard Weinberger
2013-09-30 8:13 ` Richard Genoud
2013-09-28 13:55 ` [PATCH 7/7] UBI: Add some asserts to ubi_attach_fastmap() Richard Weinberger
2013-09-30 8:16 ` Richard Genoud
2013-10-03 16:44 ` UBI fastmap updates 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=1380818515.18862.0.camel@sauron.fi.intel.com \
--to=dedekind1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard.genoud@gmail.com \
--cc=richard@nod.at \
/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;
as well as URLs for NNTP newsgroup(s).