Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1420482 > unrolled thread
| Started by | Adrian Hunter <adrian.hunter@intel.com> |
|---|---|
| First post | 2016-06-13 08:40 +0200 |
| Last post | 2016-06-23 04:10 +0200 |
| Articles | 11 — 4 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH] mmc: core: add auto bkops support Adrian Hunter <adrian.hunter@intel.com> - 2016-06-13 08:40 +0200
Re: [PATCH] mmc: core: add auto bkops support Shawn Lin <shawn.lin@rock-chips.com> - 2016-06-13 09:50 +0200
Re: [PATCH] mmc: core: add auto bkops support Adrian Hunter <adrian.hunter@intel.com> - 2016-06-13 10:30 +0200
Re: [PATCH] mmc: core: add auto bkops support Shawn Lin <shawn.lin@rock-chips.com> - 2016-06-13 11:00 +0200
Re: [PATCH] mmc: core: add auto bkops support Adrian Hunter <adrian.hunter@intel.com> - 2016-06-13 14:40 +0200
Re: [PATCH] mmc: core: add auto bkops support Ulf Hansson <ulf.hansson@linaro.org> - 2016-06-22 12:30 +0200
Re: [PATCH] mmc: core: add auto bkops support Alex Lemberg <Alex.Lemberg@sandisk.com> - 2016-06-22 16:30 +0200
Re: [PATCH] mmc: core: add auto bkops support Ulf Hansson <ulf.hansson@linaro.org> - 2016-06-22 16:30 +0200
Re: [PATCH] mmc: core: add auto bkops support Alex Lemberg <Alex.Lemberg@sandisk.com> - 2016-06-22 17:00 +0200
Re: [PATCH] mmc: core: add auto bkops support Ulf Hansson <ulf.hansson@linaro.org> - 2016-06-22 17:10 +0200
Re: [PATCH] mmc: core: add auto bkops support Shawn Lin <shawn.lin@rock-chips.com> - 2016-06-23 04:10 +0200
| From | Adrian Hunter <adrian.hunter@intel.com> |
|---|---|
| Date | 2016-06-13 08:40 +0200 |
| Subject | Re: [PATCH] mmc: core: add auto bkops support |
| Message-ID | <rJtHr-2y5-5@gated-at.bofh.it> |
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? Because then, what is the point of power off notification? And why is AUTO_EN persistent across power failure?
[toc] | [next] | [standalone]
| From | Shawn Lin <shawn.lin@rock-chips.com> |
|---|---|
| Date | 2016-06-13 09:50 +0200 |
| Message-ID | <rJuNc-3cZ-37@gated-at.bofh.it> |
| In reply to | #1420482 |
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
[toc] | [prev] | [next] | [standalone]
| From | Adrian Hunter <adrian.hunter@intel.com> |
|---|---|
| Date | 2016-06-13 10:30 +0200 |
| Message-ID | <rJvpU-3Ie-11@gated-at.bofh.it> |
| In reply to | #1420541 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Shawn Lin <shawn.lin@rock-chips.com> |
|---|---|
| Date | 2016-06-13 11:00 +0200 |
| Message-ID | <rJvT1-3Sn-31@gated-at.bofh.it> |
| In reply to | #1420589 |
在 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
[toc] | [prev] | [next] | [standalone]
| From | Adrian Hunter <adrian.hunter@intel.com> |
|---|---|
| Date | 2016-06-13 14:40 +0200 |
| Message-ID | <rJzjQ-6gW-27@gated-at.bofh.it> |
| In reply to | #1420637 |
On 13/06/16 11:58, Shawn Lin wrote: > 在 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? That would be consistent with manual bkops.
[toc] | [prev] | [next] | [standalone]
| From | Ulf Hansson <ulf.hansson@linaro.org> |
|---|---|
| Date | 2016-06-22 12:30 +0200 |
| Message-ID | <rMNzX-28F-3@gated-at.bofh.it> |
| In reply to | #1420782 |
On 13 June 2016 at 14:25, Adrian Hunter <adrian.hunter@intel.com> wrote: > On 13/06/16 11:58, Shawn Lin wrote: >> 在 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? > > That would be consistent with manual bkops. > From my first impression I agree, as that is the policy we have been sticking to when writing to persistent EXT_CSD registers. Although, in this case, I am actually wondering on what is the best approach. Is there really ever a case when we don't want auto BKOPS to be default enabled? I think BKOPS is a fundamental feature of an FTL and I can't see a reason to why we need to involve mmc-utils/userspace to enable it. Am I wrong? Kind regards Uffe
[toc] | [prev] | [next] | [standalone]
| From | Alex Lemberg <Alex.Lemberg@sandisk.com> |
|---|---|
| Date | 2016-06-22 16:30 +0200 |
| Message-ID | <rMRke-4AB-19@gated-at.bofh.it> |
| In reply to | #1428662 |
On 6/22/16, 1:21 PM, "Ulf Hansson" <ulf.hansson@linaro.org> wrote: >On 13 June 2016 at 14:25, Adrian Hunter <adrian.hunter@intel.com> wrote: >> On 13/06/16 11:58, Shawn Lin wrote: >>> 在 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? >> >> That would be consistent with manual bkops. >> > >From my first impression I agree, as that is the policy we have been >sticking to when writing to persistent EXT_CSD registers. >Although, in this case, I am actually wondering on what is the best approach. > >Is there really ever a case when we don't want auto BKOPS to be default enabled? >I think BKOPS is a fundamental feature of an FTL and I can't see a >reason to why we need to involve mmc-utils/userspace to enable it. Am >I wrong? The even worst case is – involve mmc-utils/userspace to DISABLE it. I think this register need to be set by vendor and no need to be changed on runtime. > >Kind regards >Uffe
[toc] | [prev] | [next] | [standalone]
| From | Ulf Hansson <ulf.hansson@linaro.org> |
|---|---|
| Date | 2016-06-22 16:30 +0200 |
| Message-ID | <rMRke-4AB-31@gated-at.bofh.it> |
| In reply to | #1428838 |
On 22 June 2016 at 16:20, Alex Lemberg <Alex.Lemberg@sandisk.com> wrote: > > > On 6/22/16, 1:21 PM, "Ulf Hansson" <ulf.hansson@linaro.org> wrote: > >>On 13 June 2016 at 14:25, Adrian Hunter <adrian.hunter@intel.com> wrote: >>> On 13/06/16 11:58, Shawn Lin wrote: >>>> 在 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? >>> >>> That would be consistent with manual bkops. >>> >> > >From my first impression I agree, as that is the policy we have been >>sticking to when writing to persistent EXT_CSD registers. >>Although, in this case, I am actually wondering on what is the best approach. >> >>Is there really ever a case when we don't want auto BKOPS to be default enabled? >>I think BKOPS is a fundamental feature of an FTL and I can't see a >>reason to why we need to involve mmc-utils/userspace to enable it. Am >>I wrong? > > The even worst case is – involve mmc-utils/userspace to DISABLE it. > I think this register need to be set by vendor and no need to be changed on runtime. If it is set by the Vendor, that's of course the best. Are you saying that we shouldn't enable it during the card init sequence from the kernel, in case it is disabled? Kind regards Uffe
[toc] | [prev] | [next] | [standalone]
| From | Alex Lemberg <Alex.Lemberg@sandisk.com> |
|---|---|
| Date | 2016-06-22 17:00 +0200 |
| Message-ID | <rMRNf-4Kq-21@gated-at.bofh.it> |
| In reply to | #1428842 |
On 6/22/16, 5:28 PM, "Ulf Hansson" <ulf.hansson@linaro.org> wrote: >On 22 June 2016 at 16:20, Alex Lemberg <Alex.Lemberg@sandisk.com> wrote: >> >> >> On 6/22/16, 1:21 PM, "Ulf Hansson" <ulf.hansson@linaro.org> wrote: >> >>>On 13 June 2016 at 14:25, Adrian Hunter <adrian.hunter@intel.com> wrote: >>>> On 13/06/16 11:58, Shawn Lin wrote: >>>>> 在 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? >>>> >>>> That would be consistent with manual bkops. >>>> >>> >> >From my first impression I agree, as that is the policy we have been >>>sticking to when writing to persistent EXT_CSD registers. >>>Although, in this case, I am actually wondering on what is the best approach. >>> >>>Is there really ever a case when we don't want auto BKOPS to be default enabled? >>>I think BKOPS is a fundamental feature of an FTL and I can't see a >>>reason to why we need to involve mmc-utils/userspace to enable it. Am >>>I wrong? >> >> The even worst case is – involve mmc-utils/userspace to DISABLE it. >> I think this register need to be set by vendor and no need to be changed on runtime. > >If it is set by the Vendor, that's of course the best. It can be set by Storage Vendor. According to the spec, the default value of this bit is vendor specific. > >Are you saying that we shouldn't enable it during the card init >sequence from the kernel, in case it is disabled? No. By the spec – a 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 byte 163] to 1b. > >Kind regards >Uffe
[toc] | [prev] | [next] | [standalone]
| From | Ulf Hansson <ulf.hansson@linaro.org> |
|---|---|
| Date | 2016-06-22 17:10 +0200 |
| Message-ID | <rMRWV-53e-3@gated-at.bofh.it> |
| In reply to | #1428875 |
[...] >>> >From my first impression I agree, as that is the policy we have been >>>>sticking to when writing to persistent EXT_CSD registers. >>>>Although, in this case, I am actually wondering on what is the best approach. >>>> >>>>Is there really ever a case when we don't want auto BKOPS to be default enabled? >>>>I think BKOPS is a fundamental feature of an FTL and I can't see a >>>>reason to why we need to involve mmc-utils/userspace to enable it. Am >>>>I wrong? >>> >>> The even worst case is – involve mmc-utils/userspace to DISABLE it. >>> I think this register need to be set by vendor and no need to be changed on runtime. >> >>If it is set by the Vendor, that's of course the best. > > It can be set by Storage Vendor. > According to the spec, the default value of this bit is vendor specific. > >> >>Are you saying that we shouldn't enable it during the card init >>sequence from the kernel, in case it is disabled? > > No. > By the spec – a 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 byte 163] to 1b. Okay, thanks! Kind regards Uffe
[toc] | [prev] | [next] | [standalone]
| From | Shawn Lin <shawn.lin@rock-chips.com> |
|---|---|
| Date | 2016-06-23 04:10 +0200 |
| Message-ID | <rN2fE-3kM-3@gated-at.bofh.it> |
| In reply to | #1428662 |
在 2016/6/22 18:21, Ulf Hansson 写道: > On 13 June 2016 at 14:25, Adrian Hunter <adrian.hunter@intel.com> wrote: >> On 13/06/16 11:58, Shawn Lin wrote: >>> 在 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? >> >> That would be consistent with manual bkops. >> > >>From my first impression I agree, as that is the policy we have been > sticking to when writing to persistent EXT_CSD persistent . > Although, in this case, I am actually wondering on what is the best approach. I don't know what is the real meaning of "persistent". :) I don't know should we count auto bkops as the persistent registers....HS_TIMING and BUS_WIDTH should also be persistent registers as them are always used after initialization if not changing them? IHMO the more reasonable way is that: IIRC many settings for EXT_CSD should be OTP, like hw-reset(162), reliable write(167) fw-configure(169)..etc, which are marked as R/W. These should be controlled by userpace or even by firmware when flashing emmc, like reliable write... I'm not sure whether should I updete this $SUBJUCT or migirating it to userspace... We need to come to an agreement :) > > Is there really ever a case when we don't want auto BKOPS to be default enabled? > I think BKOPS is a fundamental feature of an FTL and I can't see a > reason to why we need to involve mmc-utils/userspace to enable it. Am > I wrong? > > Kind regards > Uffe > > > -- Best Regards Shawn Lin
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web