linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Quentin Schulz <quentin.schulz@bootlin.com>
Cc: dedekind1@gmail.com, richard@nod.at, dwmw2@infradead.org,
	computersforpeace@gmail.com, marek.vasut@gmail.com,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	thomas.petazzoni@bootlin.com
Subject: Re: [PATCH 2/2] ubi: introduce ubi.nocheck parameter to skip CRC check when attaching ubi vol
Date: Fri, 20 Apr 2018 19:19:24 +0200	[thread overview]
Message-ID: <20180420191924.18b81e96@bbrezillon> (raw)
In-Reply-To: <6551534f88b3aa77cc377c4270c4ddf7fe92cdf4.1524214122.git-series.quentin.schulz@bootlin.com>

On Fri, 20 Apr 2018 10:52:41 +0200
Quentin Schulz <quentin.schulz@bootlin.com> wrote:

> There's already ECC on NAND pages so there may be no need for one to
> check the CRC of a UBI volume.

That's true that ECC can help detecting corruptions, but I don't think
this is the actual reason for disabling CRC check at volume open time.
The actual reason for doing that is when the UBI volume user (in our
case the squashfs FS) is also checking data consistency on its own
(which is the case for squashfs).

> 
> Let's introduce a ubi.nocheck parameter that let one skip the CRC check
> when attaching a UBI volume.
> 
> This also drastically speeds kernel boot by removing a potentially
> useless check, e.g. I gained 3.2s on boot time of a SPEAr600-based board
> for a ~20MB UBI volume used as rootfs.

Can you give the old and new open/mount time instead of telling how
much you gained on the whole boot-time?

  parent reply	other threads:[~2018-04-20 17:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-20  8:52 [PATCH 1/2] ubi: move constants for ubi vol parsing from kernel param to ubi.h Quentin Schulz
2018-04-20  8:52 ` [PATCH 2/2] ubi: introduce ubi.nocheck parameter to skip CRC check when attaching ubi vol Quentin Schulz
2018-04-20  9:37   ` Richard Weinberger
2018-04-20  9:50     ` Quentin Schulz
2018-06-11 10:20     ` Quentin Schulz
2018-06-14  7:29       ` Richard Weinberger
2018-06-14  8:04         ` Boris Brezillon
2018-06-14  8:07           ` Richard Weinberger
2018-04-20 17:19   ` Boris Brezillon [this message]
2018-04-23  9:40     ` Quentin Schulz
2018-04-23 12:08       ` Boris Brezillon

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=20180420191924.18b81e96@bbrezillon \
    --to=boris.brezillon@bootlin.com \
    --cc=computersforpeace@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=quentin.schulz@bootlin.com \
    --cc=richard@nod.at \
    --cc=thomas.petazzoni@bootlin.com \
    /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;
as well as URLs for NNTP newsgroup(s).