linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shawn Lin <shawn.lin@rock-chips.com>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: shawn.lin@rock-chips.com, Ulf Hansson <ulf.hansson@linaro.org>,
	Jaehoon Chung <jh80.chung@samsung.com>,
	linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
	Doug Anderson <dianders@chromium.org>,
	linux-rockchip@lists.infradead.org,
	Alex Lemberg <alex.lemberg@sandisk.com>
Subject: Re: [PATCH] mmc: core: add auto bkops support
Date: Mon, 13 Jun 2016 15:48:15 +0800	[thread overview]
Message-ID: <8bbb3f13-efb3-e963-e53f-cf2ca796f319@rock-chips.com> (raw)
In-Reply-To: <575E52AC.6000902@intel.com>

On 2016/6/13 14:29, Adrian Hunter wrote:
> On 06/06/16 06:07, Shawn Lin wrote:
>> JEDEC eMMC v5.1 introduce an autonomously initiated method
>> for background operations.
>>
>> Host that wants to enable the device to perform background
>> operations during device idle time, should signal the device
>> by setting AUTO_EN in BKOPS_EN field EXT_CSD[163] to 1b. When
>> this bit is set, the device may start or stop background operations
>> whenever it sees fit, without any notification to the host.
>>
>> When AUTO_EN bit is set, the host should keep the device power
>> active. The host may set or clear this bit at any time based on
>> its power constraints or other considerations.
>>
>> Currently the manual bkops is only be used under the async req
>> circumstances and it's a bit complicated to be controlled as the
>> perfect method is that we should do some idle monitor just as rpm
>> and send HPI each time if receiving rd/wr req. But it will impact
>> performance significantly, especially for random iops since the
>> weight of executing HPI against r/w small piece of LBAs is
>> nonnegligible.
>>
>> So we now prefer to select the auto one unconditionally if supported
>> which makes it as simple as possible. It should really good enough
>> for devices to manage its internal policy for bkops rather than the
>> host, which makes us believe that we could achieve the best
>> performance for all the devices implementing auto bkops and the only
>> thing we should do is to disable it when cutting off the power.
>
> Do you know if there is really a requirement to do that?

Even without bkops enable, no matter for manual or auto one, FTL should
always do bkops like GC internally when needed to guarantee the
performance and balance the wear leveling. What I thought to do is to
make it more explicitly.

Because then, what
> is the point of power off notification?

When power off notification is sent, bkops will be stopped
in _mmc_suspend. So I don't undertand your point here?

And why is AUTO_EN persistent across
> power failure?

Ahh, that's a problem need to be fixed, thanks for reminding.

>
>
>
>


-- 
Best Regards
Shawn Lin

  reply	other threads:[~2016-06-13  7:48 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-06  3:07 [PATCH] mmc: core: add auto bkops support Shawn Lin
2016-06-08 14:46 ` Alex Lemberg
2016-06-12  1:13   ` Shawn Lin
2016-06-20 13:33     ` Alex Lemberg
2016-06-21  0:38       ` Jaehoon Chung
2016-06-21  1:44       ` Shawn Lin
2016-06-22 14:08         ` Alex Lemberg
2016-06-23  1:33           ` Shawn Lin
2016-06-23  5:22             ` Adrian Hunter
2016-06-27  9:08               ` Ulf Hansson
2016-06-27 11:30                 ` Alex Lemberg
2016-06-13  6:29 ` Adrian Hunter
2016-06-13  7:48   ` Shawn Lin [this message]
2016-06-13  8:17     ` Adrian Hunter
2016-06-13  8:58       ` Shawn Lin
2016-06-13 12:25         ` Adrian Hunter
2016-06-22 10:21           ` Ulf Hansson
2016-06-22 14:20             ` Alex Lemberg
2016-06-22 14:28               ` Ulf Hansson
2016-06-22 14:57                 ` Alex Lemberg
2016-06-22 15:03                   ` Ulf Hansson
2016-06-23  2:08             ` Shawn Lin
2016-06-27  9:00               ` Ulf Hansson

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=8bbb3f13-efb3-e963-e53f-cf2ca796f319@rock-chips.com \
    --to=shawn.lin@rock-chips.com \
    --cc=adrian.hunter@intel.com \
    --cc=alex.lemberg@sandisk.com \
    --cc=dianders@chromium.org \
    --cc=jh80.chung@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=ulf.hansson@linaro.org \
    /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).