From: Artem Bityutskiy <dedekind@infradead.org>
To: Konstantin Baydarov <kbaidarov@dev.rtsoft.ru>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH] [MTD] NAND: Lazily BBT construction
Date: Fri, 24 Nov 2006 15:01:39 +0200 [thread overview]
Message-ID: <1164373299.576.11.camel@sauron> (raw)
In-Reply-To: <20061124154210.6303c9fe@localhost.localdomain>
On Fri, 2006-11-24 at 15:42 +0300, Konstantin Baydarov wrote:
> This is the implementation of lazy BBT construction. It introduces
> a new config option that allows to construct BBT(bad block table)
> lazily for NAND chips with memory based BBT.
> The main goal of the feature introduced is to decrease boot time.
> How it works: BBT is filled only when we check if block is bad. NAND
> is
> scanned and BBT entries is constructed from topmost unscanned block to
> requested.
> By default BBT is constructed during boot. To enable lazily
> construction NAND_LAZY_BBT bit should be set in options field of
> structure nand_chip.
The idea looks nice. But I still have 2 questions.
1. Why don't you instead spawn a scanning kernel thread and do not build
BBT in background. After the flash is scanned you just kill the thread.
Also you block any task which accesses an unscanned eraseblock till the
scanning thread scanned this eraseblock.
2. nand_base.c looks quite complex now. I wonder if it makes sense to do
lazy BBT building always, I mean not to introduce this option but make
it the only and default way? Well, it may make boot time a bit longer in
case of small flashes, but I am not sure we should care.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
next prev parent reply other threads:[~2006-11-24 13:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-24 12:42 [PATCH] [MTD] NAND: Lazily BBT construction Konstantin Baydarov
2006-11-24 13:01 ` Artem Bityutskiy [this message]
2006-11-24 13:11 ` Vitaly Wool
2006-11-24 15:42 ` Artem Bityutskiy
2006-11-24 13:05 ` Artem Bityutskiy
2006-11-24 13:56 ` Konstantin Baydarov
2006-11-24 15:45 ` 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=1164373299.576.11.camel@sauron \
--to=dedekind@infradead.org \
--cc=kbaidarov@dev.rtsoft.ru \
--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