Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1197163
| From | Andrea Scian <rnd4@dave-tech.it> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH 2/2] mtd: nand: use nand_check_erased_ecc_chunk in default ECC read functions |
| Date | 2015-07-31 18:20 +0200 |
| Message-ID | <pSlcm-2vJ-11@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <pRZYe-5cb-21@gated-at.bofh.it> <pSfqi-2mC-23@gated-at.bofh.it> <pSfTk-2UX-31@gated-at.bofh.it> <pSiRe-7bu-47@gated-at.bofh.it> <pSjkd-8dP-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Il 31/07/2015 16:10, Boris Brezillon ha scritto: > On Fri, 31 Jul 2015 15:40:13 +0200 > Andrea Scian <rnd4@dave-tech.it> wrote: > >> >> Boris, >> >> Il 31/07/2015 12:32, Boris Brezillon ha scritto: >>> Hi Andrea, >>> >>> Adding Han in Cc. >>> >>> On Fri, 31 Jul 2015 12:07:21 +0200 >>> Andrea Scian <rnd4@dave-tech.it> wrote: >>> >>>> >>>> Dear Boris, >>>> >>>> >>>> Il 30/07/2015 19:34, Boris Brezillon ha scritto: >>>>> The default NAND read functions are relying on an underlying controller >>>>> to correct bitflips, but some of those controller cannot properly fix >>>>> bitflips in erased pages. >>>>> In case of ECC failures, check if the page of subpage is empty before >>>>> reporting an ECC failure. >>>> >>>> I'm still wondering if chip->ecc.strength is the right threshold. >>>> >>>> Did you see my comments here [1]? WDYT? >>> >>> Yes I've read it, and decided to go for ecc->strength as a first >>> step (I'm more interested in discussing the approach than the threshold >>> value right now ;-)). >> >> I perfectly understand, that's the reason why I ask if you want to move >> to another thread ;-) >> >>> Anyway, as you pointed out in the thread, writing data on an erased >>> page already containing some bitflips might generate even more >>> bitflips, so using a different threshold for the erased page check >>> makes sense. This threshold should definitely be correlated to the ECC >>> strength, but how, that's the question. >>> >>> How about taking a rather conservative value like 10% of the specified >>> ECC strength, and see how it goes. >> >> Yes, I think that there's no real way to get the right value, other than >> feedbacks from on-field testing with various devices. >> >> I'm also thinking about changing how a NAND page is written on the >> device, now that we know that even erased page may have (too many!) >> bitflips if they has not been so-freshly erased. >> >> Read on NAND device is lot's faster that write, so maybe we can: >> >> a) read the page before write it, check for bitflips on erased area and >> write it only if it fit our threshold >> >> b) read the page after write it and check if the bitflips are lower that >> a give value >> >> In this way: >> - we can use ecc_strength as read threshold, because it fits all the >> other NAND read >> >> - we can use "something a bit lower than" mtd->bitflip_threshold on >> read-before-write or read-after-write. If we don't do so the block will >> be scrubbed next time we read it again (if we are lucky.. if we are >> unlucky the block will have bitflip > ecc_strength!): IOW we did a write >> that will trigger another erase/write cycle. >> >> Am I misunderstanding something? > > Nope, but this implies doing an extra read after each write :-/ > Let's wait what the others says about this, but I would like to put some numbers in it. My micron MLC device says - read page max 75 uS - write page typ 1300uS, max 2600uS If we implement read-before-write (which is, IMO, the best approach), in the worst overhead we have is 1375uS vs 1300uS, which is ~6%. Please note that, if you read a page that "is not suitable" for write, you avoid the write time, schedule it for scrubbing, and use another free page. Probably I'm a bit optimistic because we also need to take in account other latencies (DMA setup, ECC engine, buffer copies and so on) but it's a starting point ;-) KR, -- Andrea SCIAN DAVE Embedded Systems -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread
Re: [RFC PATCH 2/2] mtd: nand: use nand_check_erased_ecc_chunk in default ECC read functions Andrea Scian <rnd4@dave-tech.it> - 2015-07-31 18:20 +0200
Re: [RFC PATCH 2/2] mtd: nand: use nand_check_erased_ecc_chunk in default ECC read functions Boris Brezillon <boris.brezillon@free-electrons.com> - 2015-07-31 18:30 +0200
Re: [RFC PATCH 2/2] mtd: nand: use nand_check_erased_ecc_chunk in default ECC read functions Andrea Scian <rnd4@dave-tech.it> - 2015-08-03 13:20 +0200
Re: [RFC PATCH 2/2] mtd: nand: use nand_check_erased_ecc_chunk in default ECC read functions Boris Brezillon <boris.brezillon@free-electrons.com> - 2015-08-03 14:50 +0200
Re: [RFC PATCH 2/2] mtd: nand: use nand_check_erased_ecc_chunk in default ECC read functions Andrea Scian <rnd4@dave-tech.it> - 2015-08-03 15:40 +0200
Re: [RFC PATCH 2/2] mtd: nand: use nand_check_erased_ecc_chunk in default ECC read functions Richard Weinberger <richard@nod.at> - 2015-08-03 21:40 +0200
Re: [RFC PATCH 2/2] mtd: nand: use nand_check_erased_ecc_chunk in default ECC read functions Andrea Scian <rnd4@dave-tech.it> - 2015-08-04 09:10 +0200
Re: [RFC PATCH 2/2] mtd: nand: use nand_check_erased_ecc_chunk in default ECC read functions Richard Weinberger <richard@nod.at> - 2015-08-04 09:30 +0200
csiph-web