public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: "George Spelvin" <linux@sciencehorizons.net>
Cc: beanhuo@micron.com, computersforpeace@gmail.com,
	linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
	richard@nod.at
Subject: Re: [PATCH 2/4] mtd: nand: implement two pairing scheme
Date: Sun, 12 Jun 2016 23:13:14 +0200	[thread overview]
Message-ID: <20160612231314.15d06854@bbrezillon> (raw)
In-Reply-To: <20160612202453.21265.qmail@ns.sciencehorizons.net>

On 12 Jun 2016 16:24:53 -0400
"George Spelvin" <linux@sciencehorizons.net> wrote:

> Boris Brezillon wrote:
> > On 12 Jun 2016 08:25:49 -0400
> > "George Spelvin" <linux@sciencehorizons.net> wrote:  
> >> (In fact, an interesting
> >> question is whether bad pages should be skipped or not!)  
> > 
> > There's no such thing. We have bad blocks, but when a block is bad all
> > the pages inside this block are considered bad. If one of the page in a
> > valid block shows uncorrectable errors, UBI/UBIFS will just refuse to
> > attach the partition/mount the FS.  
> 
> Ah, okay.  I guess dealing with inconsistently-sized blocks is too much
> hassle.  And a block has a single program/erase cycle count, so if one
> part is close to wearing out, the rest is, too.
> 
> P.S. interesting NASA study of (SLC) flash disturb effects:
> http://nepp.nasa.gov/DocUploads/9CCA546D-E7E6-4D96-880459A831EEA852/07-100%20Sheldon_JPL%20Distrub%20Testing%20in%20Flash%20Mem.pdf?q=disturb-testing-in-flash-memories

Thanks for the link.

> 
> One thing they noted was that manufacturers' bad-blocck testing sucked,
> and quite a few "bad" blocks became good and stayed good over time.
> 
> >> Given that, very predictable writer ordering, it would make sense to
> >> precompensate for write disturb.  
> > 
> > Yes, that's what I assumed, but this is not clearly documented.
> > Actually, I discovered that while trying to solve the paired pages
> > problem (when I was partially programming a block, it was showing
> > uncorrectable errors sooner than the fully written ones).  
> 
> Were the errors in a predictable direction?  My understanding is that
> write disturb tends to add a little extra charge to the disturbed
> floating gates (i.e. write them more toward 0), so you'd expect
> to see extra 1s if the chip was underprogramming in antiipation.
> 
> I'm also having a hard time figuring out the bit assignment.
> In general, "1" means uncharged floating gate and "0" means charged,
> but different sources show different encodings for MLC.
> 
> Some (e.g. the NASA report above) show the progression from erased to
> programmed as
> 
> 11 - 10 - 01 - 00
> 
> so the msbit is a "big jump" and the lsbit is a "small jump", and to
> program it in SLC mode you'd program both pages identically, then read
> back the msbit.
> 
> 
> Others, e.g.
> http://users.ece.cmu.edu/~omutlu/pub/flash-programming-interference_iccd13.pdf
> suggest the order is
> 
> 11 - 10 - 00 - 01
> 
> This has the advantage that a 1-level mis-read only produces a 1-bit
> error.
> 
> But in this case, to get SLC programming, you program the lsbit as
> all-ones.
> 
> My problem is that I don't really understand MLC programming.

I came to the same conclusion: we really have these 2 cases in the
wild, which makes it even more complicated to define a standard
behavior.

> 
> 
> >>> [2]http://www.szyuda88.com/uploadfile/cfile/201061714220663.pdf    
> >> 
> >> Did you see the footnote at the bottom of p. 64 of the latter?
> >> Does that affect your pair/group addressing scheme?
> >> 
> >> It seems they are grouping not just 8K pages into even/odd double-pages,
> >> and those 16K double-pages are being addressed with stride of 3.
> >> 
> >> But in particular, an interrupted write is likely to corrupt both
> >> double-pages, 32K of data!  
> > 
> > Yes, that's yet another problem I decided to ignore for now :).
> > 
> > I guess a solution would be to consider that all 4 pages are 'paired'
> > together, but this also implies considering that the NAND is a 4-level
> > cells, which will make us loose even more space when operating in 'SLC
> > mode' where we only write the lower page (page attached to group 0) of
> > each pair.  
> 
> It's more considering it to have 16K pages that can be accessed in half-pages.

Yes, I know, but it's not really easy to fake that at the NAND level,
because programming 2 pages still requires 2 page program operation.
The MTD user could detect that the pairing scheme always exposes 2
consecutive non-paired pages, but as you've seen, this condition does
not necessarily imply the 'pair coupling' constraint, and we don't want
to increase the min_io_size value if it's not really necessary.


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

  reply	other threads:[~2016-06-12 21:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-11 22:30 [PATCH 2/4] mtd: nand: implement two pairing scheme George Spelvin
2016-06-12  7:20 ` Boris Brezillon
2016-06-12  9:23   ` George Spelvin
2016-06-12 11:11     ` Boris Brezillon
2016-06-12 12:25       ` George Spelvin
2016-06-12 12:42         ` Boris Brezillon
2016-06-12 15:10           ` Boris Brezillon
2016-06-12 20:24           ` George Spelvin
2016-06-12 21:13             ` Boris Brezillon [this message]
2016-06-12 21:37               ` Boris Brezillon
2016-06-14  9:07               ` George Spelvin
2016-06-14  9:34                 ` Boris Brezillon
2016-06-14 20:29                 ` Boris Brezillon
  -- strict thread matches above, loose matches on Subject: below --
2016-04-25 10:01 [PATCH 0/4] mtd: add support for pairing scheme description Boris Brezillon
2016-04-25 10:01 ` [PATCH 2/4] mtd: nand: implement two pairing scheme 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=20160612231314.15d06854@bbrezillon \
    --to=boris.brezillon@free-electrons.com \
    --cc=beanhuo@micron.com \
    --cc=computersforpeace@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux@sciencehorizons.net \
    --cc=richard@nod.at \
    /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