From: Artem Bityutskiy <dedekind@infradead.org>
To: Hamish Moffatt <hamish@cloud.net.au>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [RFC] slight UBI scan time improvement
Date: Thu, 24 Apr 2008 09:21:20 +0300 [thread overview]
Message-ID: <1209018080.11721.88.camel@sauron> (raw)
In-Reply-To: <20080424015303.GB13358@cloud.net.au>
On Thu, 2008-04-24 at 11:53 +1000, Hamish Moffatt wrote:
> Thanks for the info. It looks like this would not save me very much
> time so I don't think I will bother.
Ok.
> 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):
Err, 64 bytes each even.
> 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.
Yes, I guess. Current MTD implementation reads whole page in any case,
though.
> 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.
However, there was a patch from Alexey which may certainly help you. It
was not looked at properly, unfortunately. I'll try to find it in my
mailbox and will send to you.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
next prev parent reply other threads:[~2008-04-24 6:21 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
2008-04-24 6:21 ` Artem Bityutskiy [this message]
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=1209018080.11721.88.camel@sauron \
--to=dedekind@infradead.org \
--cc=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 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.