Re: [RFC PATCH 2/2] mtd: nand: use nand_check_erased_ecc_chunk in default ECC read functions

[Andrea Scian]

Richard,

Il 03/08/2015 21:32, Richard Weinberger ha scritto:
> Am 03.08.2015 um 15:39 schrieb Andrea Scian:
> > > > I think I can find some time to do some performance tests on real hardware.
> > > > Can you please help me in finding:
> > > > - which benchmark to use (currently I'm using bonnie++ on UBIFS, maybe I
> > > > can you just mtd_speedtest)
> > > > - where to implement those read
> > >
> > > I think the test should be done at the UBI layer if we want to check
> > > the real impact of the additional read sequence, but given the answer I
> > > gave to your other question I'm not sure this is relevant anymore ;-).
>
> I'm not sure whether introducing a read-before-write check is the best solution.
> At least we need hard numbers for slow/old SLC NANDs too.

We can enable the feature only for MLC, AFAIK it has not been required 
for old SLC ;-)

Anyway, maybe I can do some performance test if you point me to the 
right userspace tool to use.
As I already say I'm using bonnie++ to stress the device, more from a 
stability than from performance point of view.
I'm also used to run mtd_speedtest but this may be useless if we put 
some code inside the upper layers.

> We has such checks already and got rid of them.
> commit 657f28f8811c92724db10d18bbbec70d540147d6
> Author: Huang Shijie <shijie8@xxxxxxxxx>
> Date:   Tue Aug 14 22:38:45 2012 -0400
>
>      mtd: kill MTD_NAND_VERIFY_WRITE
>
>
> Although the goal of 657f28f8 was something else.

Understood, thanks for point this out

> In general I don't think putting much MTD/ECC logic into UBI is the way to go.
> UBI is a layer above MTD and MTD should do as much as possible wrt. ECC.
>
> > > > For the second point I think we can implement it a UBI or MTD level.
> > > > I think the former will allow us to easily schedule scrubbing and choose
> > > > another block to issue the write to. However I don't really know how to
> > > > implement it (I don't really know so much about the UBI code).
>
> Implementing this is not much work.
> I've done such hacks for various customers to hunt down hardware issues.
>
> > > I didn't check before suggesting that, but it seems that the UBI layer
> > > is already doing this check for you [1], so if you're using UBI/UBIFS
> > > you shouldn't worry about bitflips in erased pages: if there is any,
> > > and their presence impact the write result, they should be detected.
> > > AFAICT, the only thing that is not checked is whether the number of
> > > bitflips after a write exceed the bitflips threshold or not, and I
> > > guess this can be added.
> >
> > IIUC this is a runtime debug check
> >
> > if (!ubi_dbg_chk_io(ubi))
> >      ....
> >
> > And thus is disabled by default.
>
> That's correct.

Thanks.
In your opinion, enabling chk_io is correct to rough estimate the 
overhead or does it enable too much checks?

TIA,

--

Andrea SCIAN

DAVE Embedded Systems
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/