From: Tanya Brokhman <tlinder@codeaurora.org>
To: Richard Weinberger <richard@nod.at>, dedekind1@gmail.com
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/6] UBI: Fastmap: Don't allocate new ubi_wl_entry objects
Date: Mon, 08 Dec 2014 10:36:21 +0200 [thread overview]
Message-ID: <54856305.2070408@codeaurora.org> (raw)
In-Reply-To: <1417347340-6872-3-git-send-email-richard@nod.at>
On 11/30/2014 1:35 PM, Richard Weinberger wrote:
> There is no need to allocate new ones every time, we can reuse
> the existing ones.
> This makes the code cleaner and more easy to follow.
>
> Signed-off-by: Richard Weinberger <richard@nod.at>
> ---
> drivers/mtd/ubi/fastmap.c | 31 +++++--------------------------
> drivers/mtd/ubi/wl.c | 11 +++++++----
> 2 files changed, 12 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/mtd/ubi/fastmap.c b/drivers/mtd/ubi/fastmap.c
> index db3defd..9507702 100644
> --- a/drivers/mtd/ubi/fastmap.c
> +++ b/drivers/mtd/ubi/fastmap.c
> @@ -1446,19 +1446,6 @@ int ubi_update_fastmap(struct ubi_device *ubi)
> }
>
> new_fm->used_blocks = ubi->fm_size / ubi->leb_size;
Not related to this patch, but looking at this function it got me
thinking: why do we need to re-calculate new_fm->used_blocks (and check
calculated value) each time? fm_size doesn't changed at runtime.
leb_size sure does not, so fm->used_blocks can be ubi device parameter
and calculated & tested only once, and not each time we write fastmap.
Correct?
> -
> - for (i = 0; i < new_fm->used_blocks; i++) {
> - new_fm->e[i] = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
> - if (!new_fm->e[i]) {
> - while (i--)
> - kfree(new_fm->e[i]);
> -
> - kfree(new_fm);
> - mutex_unlock(&ubi->fm_mutex);
> - return -ENOMEM;
> - }
> - }
> -
> old_fm = ubi->fm;
> ubi->fm = NULL;
>
Thanks,
Tanya Brokhman
--
Qualcomm Israel, on behalf of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2014-12-08 8:36 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-30 11:35 Fastmap update v2 (pile 2) Richard Weinberger
2014-11-30 11:35 ` [PATCH 1/6] UBI: Fastmap: Fix memory leaks while closing the WL sub-system Richard Weinberger
2014-12-07 8:13 ` Tanya Brokhman
2014-12-07 9:54 ` Richard Weinberger
2014-12-07 11:32 ` Tanya Brokhman
2014-12-07 11:34 ` Richard Weinberger
2014-12-07 13:26 ` Tanya Brokhman
2014-12-07 13:46 ` Richard Weinberger
2014-12-17 20:01 ` Guido Martínez
2014-11-30 11:35 ` [PATCH 2/6] UBI: Fastmap: Don't allocate new ubi_wl_entry objects Richard Weinberger
2014-12-07 13:49 ` Tanya Brokhman
2014-12-08 8:36 ` Tanya Brokhman [this message]
2014-12-08 9:14 ` Richard Weinberger
2014-12-08 9:37 ` Tanya Brokhman
2014-12-08 9:39 ` Richard Weinberger
2014-12-18 1:18 ` Guido Martínez
2014-12-18 1:21 ` Richard Weinberger
2014-11-30 11:35 ` [PATCH 3/6] UBI: Fastmap: Notify user in case of an ubi_update_fastmap() failure Richard Weinberger
2014-12-07 13:59 ` Tanya Brokhman
2014-12-07 14:22 ` Richard Weinberger
2014-12-08 6:58 ` Tanya Brokhman
2014-12-08 9:11 ` Richard Weinberger
2014-12-08 13:00 ` Tanya Brokhman
2014-12-08 13:07 ` Richard Weinberger
2014-12-08 13:20 ` Richard Weinberger
2014-11-30 11:35 ` [PATCH 4/6] UBI: Fastmap: Wrap fastmap specific function in a ifdef Richard Weinberger
2014-12-07 14:05 ` Tanya Brokhman
2014-11-30 11:35 ` [PATCH 5/6] UBI: Fastmap: Fix fastmap usage in ubi_volume_notify() Richard Weinberger
2014-12-07 14:06 ` Tanya Brokhman
2014-11-30 11:35 ` [PATCH 6/6] UBI: Fastmap: Fix memory leak while attaching Richard Weinberger
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=54856305.2070408@codeaurora.org \
--to=tlinder@codeaurora.org \
--cc=dedekind1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--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
Powered by JetHome