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 11:37:25 +0200 [thread overview]
Message-ID: <54857155.3040801@codeaurora.org> (raw)
In-Reply-To: <54856BE6.5090003@nod.at>
On 12/8/2014 11:14 AM, Richard Weinberger wrote:
> Am 08.12.2014 um 09:36 schrieb Tanya Brokhman:
>> 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?
>
> If you dig deeper into the patch set you'll notice that the fastmap size can change. :-)
>
oh, ok. sorry, still in the middle of the review.
> Thanks,
> //richard
>
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 9:37 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
2014-12-08 9:14 ` Richard Weinberger
2014-12-08 9:37 ` Tanya Brokhman [this message]
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=54857155.3040801@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