mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Amit Kumar Sharma <amitsharma.9@samsung.com>
To: Artem Bityutskiy <dedekind@infradead.org>, linux-fsdevel@vger.kernel.org
Cc: linux-mtd@lists.infradead.org,
	Adrian Hunter <ext-adrian.hunter@nokia.com>,
	linux-kernel@vger.kernel.org
Subject: Re: What is in ubifs-2.6.git
Date: Tue, 30 Sep 2008 14:25:42 +0530	[thread overview]
Message-ID: <EC8994007A40495FA924271106803A63@sisodomain.com> (raw)
In-Reply-To: <1222766358-21886-1-git-send-email-dedekind@infradead.org>

Hi Artem

OneNAND can support for full block read also in sync burst 
block read mode ,so why u want to limit bulk read only for 4 
pages , with sync burst enable u can read max 64 pages.
so in place of max 4 pages , u can set max to 64 it will be 
improve performance if sync burst mode is upported.

Rgs
Amit
----- Original Message ----- 
From: "Artem Bityutskiy" <dedekind@infradead.org>
To: <linux-fsdevel@vger.kernel.org>
Cc: <linux-mtd@lists.infradead.org>; "Adrian Hunter" 
<ext-adrian.hunter@nokia.com>; 
<linux-kernel@vger.kernel.org>
Sent: Tuesday, September 30, 2008 2:48 PM
Subject: What is in ubifs-2.6.git


> Hi,
>
> here is the stuff we have scheduled for 2.6.28. The 
> patches
> contains various small fixes and cleanups, but there is 
> something
> interesting as well.
>
> The first interesting thing is new "bulk read" 
> functionality. The
> idea is that many NAND flashes support "bulk read" in some 
> form.
> For example, OneNAND has "read while load" feature, which 
> allows
> reading consecutive NAND pages faster than reading them 
> one-by-one.
>
> So we've made UBIFS benefit from this feature and 
> introduced new
> "bulk_read" mount option. With this option enabled UBIFS 
> reads files
> a little ahead if the file data sits in consecutive 
> physical
> addresses. For example, if user-space asks to read page 
> zero of a
> file, and page 0-4 are in consecutive flash addressed, 
> UBIFS reads
> pages 0-4 and populates them to the Page Cache.
>
> Note, this is disabled by default and UBIFS has to be 
> explicitly
> mounted mounted with "bulk_read" option. The reason for 
> this is
> that we consider this feature as experimental so far.
>
> Note, UBIFS does not use VFS read-ahead and actually 
> explicitly
> disables it. This is because MTD is synchronous and all 
> I/O is
> done synchronously, so read-ahead actually slows things 
> down for
> UBIFS, instead of improving them. So the "bulk read" 
> feature is
> basically internal UBIFS read-ahead implementation.
>
> We are able to gain 4-5MiB/s of read speed on OneNAND with 
> bulk
> read enabled.
>
> The second interesting thing is new "no_chk_data_crc" 
> mount option
> which disables data CRC32 checking.
>
> UBIFS always checks CRC of everything it reads from flash 
> by default.
> On ARM platform this results in ~30% of total CPU usage in 
> profiles,
> which is quite high. But many modern flashes are very 
> reliable
> (e.g., OneNAND), and one does not need that level of 
> protection.
> So now it is possible to disable CRC checking for _data_. 
> However:
>
> * internal indexing information CRC is always checked;
> * when replaying the journal, data CRC is always checked;
> * on write, CRC is always calculated.
>
> With this mount option we are able to gain another 
> 4-5MiB/s of read
> speed on OneNAND. And together with bulk-read, the read 
> speed becomes
> ~10MiB/s faster.
>
> Adrian Hunter (11):
>      UBIFS: add bulk-read facility
>      UBIFS: add no_chk_data_crc mount option
>      UBIFS: improve znode splitting rules
>      UBIFS: correct key comparison
>      UBIFS: ensure data read beyond i_size is zeroed out 
> correctly
>      UBIFS: allow for sync_fs when read-only
>      UBIFS: improve garbage collection
>      UBIFS: fix bulk-read handling uptodate pages
>      UBIFS: add more debugging messages for LPT
>      UBIFS: correct condition to eliminate unecessary 
> assignment
>      UBIFS: check buffer length when scanning for LPT 
> nodes
>
> Artem Bityutskiy (9):
>      UBIFS: add a print, fix comments and more minor stuff
>      UBIFS: inline one-line functions
>      UBIFS: check data CRC when in error state
>      UBIFS: use bit-fields when possible
>      UBIFS: fix races in bit-fields
>      UBIFS: fix commentary
>      UBIFS: update dbg_dump_inode
>      UBIFS: correct comment for commit_on_unmount
>      UBIFS: commit on sync_fs
>
> Hirofumi Nakagawa (1):
>      UBIFS: remove unneeded unlikely()
>
> Julien Brunel (1):
>      UBIFS: use an IS_ERR test rather than a NULL test
>
> Documentation/filesystems/ubifs.txt |    9 +
> fs/ubifs/budget.c                   |   26 ++--
> fs/ubifs/debug.c                    |   79 +++++++--
> fs/ubifs/debug.h                    |    6 +
> fs/ubifs/file.c                     |  260 
> ++++++++++++++++++++++++++
> fs/ubifs/find.c                     |    4 +-
> fs/ubifs/gc.c                       |   90 ++++++++--
> fs/ubifs/io.c                       |   12 +-
> fs/ubifs/key.h                      |   22 ++-
> fs/ubifs/lprops.c                   |   34 +----
> fs/ubifs/lpt.c                      |    3 +-
> fs/ubifs/lpt_commit.c               |  187 
> ++++++++++++++++++-
> fs/ubifs/misc.h                     |   27 +++
> fs/ubifs/scan.c                     |    2 +-
> fs/ubifs/super.c                    |  109 +++++++++--
> fs/ubifs/tnc.c                      |  345 
> ++++++++++++++++++++++++++++++++---
> fs/ubifs/tnc_misc.c                 |    4 +-
> fs/ubifs/ubifs-media.h              |    1 -
> fs/ubifs/ubifs.h                    |   85 +++++++--
> fs/ubifs/xattr.c                    |    2 +-
> 20 files changed, 1149 insertions(+), 158 deletions(-)
>
> --
> Best regards,
> Artem Bityutskiy (?龜???克龜橘 ????劇)
>
>


--------------------------------------------------------------------------------


> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 



  parent reply	other threads:[~2008-09-30  8:53 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-30  9:18 Artem Bityutskiy
2008-09-30  7:56 ` Artem Bityutskiy
2008-09-30  8:55 ` Amit Kumar Sharma [this message]
2008-09-30  9:02   ` Artem Bityutskiy
2008-09-30  9:18 ` [PATCH] UBIFS: add a print, fix comments and more minor stuff Artem Bityutskiy
2008-09-30  9:18 ` [PATCH] UBIFS: remove unneeded unlikely() Artem Bityutskiy
2008-09-30  9:18 ` [PATCH] UBIFS: inline one-line functions Artem Bityutskiy
2008-09-30  9:19 ` [PATCH] UBIFS: use an IS_ERR test rather than a NULL test Artem Bityutskiy
2008-09-30  9:19 ` [PATCH] UBIFS: add bulk-read facility Artem Bityutskiy
2008-09-30  9:19 ` [PATCH] UBIFS: add no_chk_data_crc mount option Artem Bityutskiy
2008-09-30  9:19 ` [PATCH] UBIFS: improve znode splitting rules Artem Bityutskiy
2008-09-30  9:19 ` [PATCH] UBIFS: check data CRC when in error state Artem Bityutskiy
2008-09-30  9:19 ` [PATCH] UBIFS: use bit-fields when possible Artem Bityutskiy
2008-09-30  9:19 ` [PATCH] UBIFS: correct key comparison Artem Bityutskiy
2008-09-30  9:19 ` [PATCH] UBIFS: ensure data read beyond i_size is zeroed out correctly Artem Bityutskiy
2008-09-30  9:19 ` [PATCH] UBIFS: fix races in bit-fields Artem Bityutskiy
2008-09-30  9:19 ` [PATCH] UBIFS: fix commentary Artem Bityutskiy
2008-09-30  9:19 ` [PATCH] UBIFS: update dbg_dump_inode Artem Bityutskiy
2008-09-30  9:19 ` [PATCH] UBIFS: correct comment for commit_on_unmount Artem Bityutskiy
2008-09-30  9:19 ` [PATCH] UBIFS: commit on sync_fs Artem Bityutskiy
2008-09-30  9:19 ` [PATCH] UBIFS: allow for sync_fs when read-only Artem Bityutskiy
2008-09-30  9:19 ` [PATCH] UBIFS: improve garbage collection Artem Bityutskiy
2008-09-30  9:19 ` [PATCH] UBIFS: fix bulk-read handling uptodate pages Artem Bityutskiy
2008-09-30  9:19 ` [PATCH] UBIFS: add more debugging messages for LPT Artem Bityutskiy
2008-09-30  9:19 ` [PATCH] UBIFS: correct condition to eliminate unecessary assignment Artem Bityutskiy
2008-09-30  9:19 ` [PATCH] UBIFS: check buffer length when scanning for LPT nodes 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=EC8994007A40495FA924271106803A63@sisodomain.com \
    --to=amitsharma.9@samsung.com \
    --cc=dedekind@infradead.org \
    --cc=ext-adrian.hunter@nokia.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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

all inboxes | Powered by JetHome®