All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	linux-mtd@lists.infradead.org
Cc: David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	tglx@linutronix.de, Peter Zijlstra <peterz@infradead.org>
Subject: Re: [RFC PATCH 2/2] mtd: ubi: wl: avoid erasing a PEB which is empty
Date: Tue, 24 Nov 2015 15:40:18 +0200	[thread overview]
Message-ID: <1448372418.23789.65.camel@gmail.com> (raw)
In-Reply-To: <56546727.3040902@linutronix.de>

On Tue, 2015-11-24 at 14:33 +0100, Sebastian Andrzej Siewior wrote:
> What will happen next? When will e1
> be removed from the protection list?

If my memory still serves me, the answer is: roughly speaking, after a
number of erase operation, which is currently defined as

/*
 * Length of the protection queue. The length is effectively equivalent t o the
 * number of (global) erase cycles PEBs are protected from the wear-leveling
 * worker.
 */
#define UBI_PROT_QUEUE_LEN 10

But if you put it to the head of the protection queue, it'll be removed
from there as soon as any LEB is "put", which effectively means
"scheduled for erasure".

Artem.

  reply	other threads:[~2015-11-24 13:40 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-23 18:09 [RFC] avoid a live lock in wear_leveling_worker() Sebastian Andrzej Siewior
2015-11-23 18:09 ` [RFC PATCH 1/2] mtd: nand: schedule() after releasing the device Sebastian Andrzej Siewior
2015-11-23 18:18   ` Peter Zijlstra
2015-11-25 17:35     ` [PATCH] mtd: nand: do FIFO processing in nand_get_device() Sebastian Andrzej Siewior
2015-11-30 16:15       ` Peter Zijlstra
2015-12-06 14:17         ` Sebastian Andrzej Siewior
2015-12-06 14:23           ` [PATCH v2] " Sebastian Andrzej Siewior
2015-12-02 18:52       ` [PATCH] " Brian Norris
2015-12-02 20:41         ` Sebastian Andrzej Siewior
2015-11-23 18:09 ` [RFC PATCH 2/2] mtd: ubi: wl: avoid erasing a PEB which is empty Sebastian Andrzej Siewior
2015-11-23 21:30   ` Richard Weinberger
2015-11-23 21:50     ` Richard Weinberger
2015-11-24  8:26     ` Sebastian Andrzej Siewior
2015-11-24  8:39       ` Richard Weinberger
2015-11-24  8:42         ` Sebastian Andrzej Siewior
2015-11-24  9:02           ` Richard Weinberger
2015-11-24  9:07             ` Sebastian Andrzej Siewior
2015-11-24  9:16               ` Richard Weinberger
2015-11-24 12:58   ` Artem Bityutskiy
2015-11-24 13:33     ` Sebastian Andrzej Siewior
2015-11-24 13:40       ` Artem Bityutskiy [this message]
2015-11-24 13:57       ` Artem Bityutskiy
2015-11-26 14:56     ` Sebastian Andrzej Siewior

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=1448372418.23789.65.camel@gmail.com \
    --to=dedekind1@gmail.com \
    --cc=bigeasy@linutronix.de \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=peterz@infradead.org \
    --cc=richard@nod.at \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.