From: Hamish Moffatt <hamish@cloud.net.au>
To: linux-mtd@lists.infradead.org
Subject: Re: [RFC] slight UBI scan time improvement
Date: Thu, 24 Apr 2008 11:53:03 +1000 [thread overview]
Message-ID: <20080424015303.GB13358@cloud.net.au> (raw)
In-Reply-To: <1208959759.11721.76.camel@sauron>
On Wed, Apr 23, 2008 at 05:09:19PM +0300, Artem Bityutskiy wrote:
> You may make it save the BBT on the flash media. So next time you boot,
> it reads the BBT from a pre-defined place (e.g., the last eraseblock)
> and that's it. It does not scan and does not waste time.
Thanks for the info. It looks like this would not save me very much
time so I don't think I will bother.
[ 0.960000] Scanning device for bad blocks
[ 1.000000] Bad eraseblock 494 at 0x03dc0000
[ 1.050000] Bad eraseblock 1300 at 0x0a280000
[ 1.140000] Bad eraseblock 2554 at 0x13f40000
[ 1.160000] Bad eraseblock 2923 at 0x16d60000
[ 1.200000] Bad eraseblock 3349 at 0x1a2a0000
[ 1.230000] Bad eraseblock 3790 at 0x1d9c0000
[ 1.250000] UBI: attaching mtd9 to ubi-1
[ 6.890000] UBI: attached mtd9 to ubi0
I notice in your patch that you read a whole min_io_size block, even
though you only need the EC and VID headers (total of 128 bytes each, or
576 bytes as a single read according to my calculation):
+ /*
+ * During scanning we read EC and VID headers at one go in to the
+ * @si->read_buf, and then check EC and VID header. This must be faster
+ * than doing 2 small read operations.
+ */
+ si->read_len = ubi->vid_hdr_offset + UBI_VID_HDR_SIZE;
+ si->read_len = ALIGN(si->read_len, ubi->min_io_size);
+ si->read_buf = kmalloc(si->read_len, GFP_KERNEL);
+ if (!si->read_buf) {
+ err = -ENOMEM;
goto out_si;
+ }
Won't reading 2K bytes be slower than 576 in some cases? If you have
soft ECC then you have to read the whole page anyway, but if you have
hardware ECC then you have no need to read the whole page into RAM.
Hmm. The software ECC seems to work internally on 256 byte blocks.
However it appears that nand_base will always read in a whole page (2K
on my flash). It should be ok to read only a 256-byte block as that's
all you need for ECC calculation? Not a whole 2K which requires 8 ECC
calculations.
Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
next prev parent reply other threads:[~2008-04-24 1:53 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-22 16:42 [RFC] slight UBI scan time improvement Artem Bityutskiy
2008-04-22 17:28 ` Bruce_Leonard
2008-04-22 18:07 ` Artem Bityutskiy
2008-04-23 7:15 ` Nancy
2008-04-23 7:32 ` Artem Bityutskiy
2008-04-23 8:01 ` Nancy
2008-04-23 8:16 ` Artem Bityutskiy
2008-04-23 9:07 ` Nancy
2008-04-23 9:13 ` Artem Bityutskiy
2008-04-23 10:51 ` Nancy
2008-04-23 10:57 ` Nancy
2008-04-23 12:24 ` Artem Bityutskiy
2008-04-23 12:23 ` Artem Bityutskiy
2008-04-23 7:38 ` Hamish Moffatt
2008-04-23 8:13 ` Matthieu CASTET
2008-04-23 8:21 ` Artem Bityutskiy
2008-04-23 9:21 ` Matthieu CASTET
2008-04-23 9:27 ` Artem Bityutskiy
2008-04-23 12:40 ` Hamish Moffatt
2008-04-23 12:57 ` Artem Bityutskiy
2008-04-23 13:42 ` Hamish Moffatt
2008-04-23 14:09 ` Artem Bityutskiy
2008-04-24 1:53 ` Hamish Moffatt [this message]
2008-04-24 6:21 ` Artem Bityutskiy
2008-04-24 7:02 ` Hamish Moffatt
2008-04-24 0:10 ` Hamish Moffatt
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=20080424015303.GB13358@cloud.net.au \
--to=hamish@cloud.net.au \
--cc=linux-mtd@lists.infradead.org \
/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