From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933514AbcFMI7H (ORCPT ); Mon, 13 Jun 2016 04:59:07 -0400 Received: from lucky1.263xmail.com ([211.157.147.134]:54038 "EHLO lucky1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933300AbcFMI7E (ORCPT ); Mon, 13 Jun 2016 04:59:04 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 1 X-MAIL-DELIVERY: 0 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 X-RL-SENDER: shawn.lin@rock-chips.com X-FST-TO: alex.lemberg@sandisk.com X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: shawn.lin@rock-chips.com X-UNIQUE-TAG: <1f6dafeb337830807f924df0ac17e4d5> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [PATCH] mmc: core: add auto bkops support To: Adrian Hunter References: <1465182439-27963-1-git-send-email-shawn.lin@rock-chips.com> <575E52AC.6000902@intel.com> <8bbb3f13-efb3-e963-e53f-cf2ca796f319@rock-chips.com> <575E6C11.8060709@intel.com> Cc: shawn.lin@rock-chips.com, Ulf Hansson , Jaehoon Chung , linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org, Doug Anderson , linux-rockchip@lists.infradead.org, Alex Lemberg From: Shawn Lin Message-ID: Date: Mon, 13 Jun 2016 16:58:54 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <575E6C11.8060709@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2016/6/13 16:17, Adrian Hunter 写道: > On 13/06/16 10:48, Shawn Lin wrote: >> 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? > > I am trying to understand why we need to do anything for auto bkops. > Since AUTO_EN is persistent, we can leave the decision whether to turn it on > to whomever provisions the device. Then we just leave it alone. > Hrm.. one possible way is to control it by mmc-utils on user space? So we should add a cmd for mmc-utils there? > > > -- Best Regards Shawn Lin