linux-tegra.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] mmc: core: don't decrement qty when calculating max_discard
@ 2013-12-17 18:02 Stephen Warren
  2013-12-18 10:32 ` Ulf Hansson
       [not found] ` <1387303344-11802-1-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
  0 siblings, 2 replies; 4+ messages in thread
From: Stephen Warren @ 2013-12-17 18:02 UTC (permalink / raw)
  To: Chris Ball
  Cc: linux-mmc-u79uwXL29TY76Z2rM5mHXA,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA, Stephen Warren, Adrian Hunter,
	Dong Aisheng, Ulf Hansson, Vladimir Zapolskiy

From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

In mmc_do_calc_max_discard(), if any value has been assigned to qty,
that value must have passed the timeout checks in the loop. Hence,
qty is the maximum number of erase blocks that fit within the timeout,
not the first value that does not fit into the timeout. In turn, this
means we don't need any special case for (qty == 1); any value of qty
needs to be multiplied by the card's erase shift, and we don't need to
decrement qty before doing so.

Without this patch, on the NVIDIA Tegra Cardhu board, the loops result
in qty == 1, which is immediately returned. This causes discard to
operate a single sector at a time, which is chronically slow. With this
patch in place, discard operates a single erase block at a time, which
is reasonably fast.

Cc: Adrian Hunter <adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Dong Aisheng <dongas86-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Vladimir Zapolskiy <vz-ChpfBGZJDbMAvxtiuMwx3w@public.gmane.org>
Fixes: e056a1b5b67b "(mmc: queue: let host controllers specify maximum discard timeout")
Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
If this makes sense, I wonder if it should be Cc: stable?
---
 drivers/mmc/core/core.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 57a2b403bf8e..dd793cf4ef46 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2150,16 +2150,13 @@ static unsigned int mmc_do_calc_max_discard(struct mmc_card *card,
 	if (!qty)
 		return 0;
 
-	if (qty == 1)
-		return 1;
-
 	/* Convert qty to sectors */
 	if (card->erase_shift)
-		max_discard = --qty << card->erase_shift;
+		max_discard = qty << card->erase_shift;
 	else if (mmc_card_sd(card))
 		max_discard = qty;
 	else
-		max_discard = --qty * card->erase_size;
+		max_discard = qty * card->erase_size;
 
 	return max_discard;
 }
-- 
1.8.1.5

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] mmc: core: don't decrement qty when calculating max_discard
  2013-12-17 18:02 [PATCH] mmc: core: don't decrement qty when calculating max_discard Stephen Warren
@ 2013-12-18 10:32 ` Ulf Hansson
       [not found] ` <1387303344-11802-1-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
  1 sibling, 0 replies; 4+ messages in thread
From: Ulf Hansson @ 2013-12-18 10:32 UTC (permalink / raw)
  To: Stephen Warren
  Cc: Chris Ball, linux-mmc, linux-tegra@vger.kernel.org,
	Stephen Warren, Adrian Hunter, Dong Aisheng, Vladimir Zapolskiy

On 17 December 2013 19:02, Stephen Warren <swarren@wwwdotorg.org> wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> In mmc_do_calc_max_discard(), if any value has been assigned to qty,
> that value must have passed the timeout checks in the loop. Hence,
> qty is the maximum number of erase blocks that fit within the timeout,
> not the first value that does not fit into the timeout. In turn, this
> means we don't need any special case for (qty == 1); any value of qty
> needs to be multiplied by the card's erase shift, and we don't need to
> decrement qty before doing so.
>
> Without this patch, on the NVIDIA Tegra Cardhu board, the loops result
> in qty == 1, which is immediately returned. This causes discard to
> operate a single sector at a time, which is chronically slow. With this
> patch in place, discard operates a single erase block at a time, which
> is reasonably fast.
>
> Cc: Adrian Hunter <adrian.hunter@intel.com>
> Cc: Dong Aisheng <dongas86@gmail.com>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Cc: Vladimir Zapolskiy <vz@mleia.com>
> Fixes: e056a1b5b67b "(mmc: queue: let host controllers specify maximum discard timeout")
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> If this makes sense, I wonder if it should be Cc: stable?
> ---
>  drivers/mmc/core/core.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 57a2b403bf8e..dd793cf4ef46 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -2150,16 +2150,13 @@ static unsigned int mmc_do_calc_max_discard(struct mmc_card *card,
>         if (!qty)
>                 return 0;
>
> -       if (qty == 1)
> -               return 1;
> -
>         /* Convert qty to sectors */
>         if (card->erase_shift)
> -               max_discard = --qty << card->erase_shift;
> +               max_discard = qty << card->erase_shift;
>         else if (mmc_card_sd(card))
>                 max_discard = qty;
>         else
> -               max_discard = --qty * card->erase_size;
> +               max_discard = qty * card->erase_size;
>
>         return max_discard;
>  }
> --
> 1.8.1.5
>

I guess this patch on it's own seems reasonable, so we should maybe
apply it as a short term solution!?

To solve the real problem, I think we shall not consider the
"max_discard_to" while calculating the max_discard value. Instead I
think we shall be able to make an estimation of a fixed number of
erase blocks (maybe considering the size of the card of something).

Then we instead calculates what busy detection timeout, this fixed
number of erase blocks, gives us.

For hosts not supporting MMC_CAP_WAIT_WHILE_BUSY, the calculated busy
detection timeout will be of less importance, since I think we should
rely on polling with CMD13 to find out when the erase operation is
completed.

For hosts supporting MMC_CAP_WAIT_WHILE_BUSY, the calculated busy
detection timeout can turn out to be bigger than what the host
supports. In this case we need to decide whether we still should
expect the host to handle busy detection but with an indefinite
timeout, or if should prevent the host from using busy detection and
do polling with CMD13 instead.

Does this make sense?

Kind regards
Ulf Hansson

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] mmc: core: don't decrement qty when calculating max_discard
       [not found] ` <1387303344-11802-1-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
@ 2013-12-18 11:08   ` Adrian Hunter
       [not found]     ` <52B1822F.8080404-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
  0 siblings, 1 reply; 4+ messages in thread
From: Adrian Hunter @ 2013-12-18 11:08 UTC (permalink / raw)
  To: Stephen Warren
  Cc: Chris Ball, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA, Stephen Warren, Dong Aisheng,
	Ulf Hansson, Vladimir Zapolskiy

On 17/12/13 20:02, Stephen Warren wrote:
> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> 
> In mmc_do_calc_max_discard(), if any value has been assigned to qty,
> that value must have passed the timeout checks in the loop. Hence,
> qty is the maximum number of erase blocks that fit within the timeout,
> not the first value that does not fit into the timeout. In turn, this
> means we don't need any special case for (qty == 1); any value of qty
> needs to be multiplied by the card's erase shift, and we don't need to
> decrement qty before doing so.
> 
> Without this patch, on the NVIDIA Tegra Cardhu board, the loops result
> in qty == 1, which is immediately returned. This causes discard to
> operate a single sector at a time, which is chronically slow. With this
> patch in place, discard operates a single erase block at a time, which
> is reasonably fast.
> 
> Cc: Adrian Hunter <adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Cc: Dong Aisheng <dongas86-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Ulf Hansson <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Vladimir Zapolskiy <vz-ChpfBGZJDbMAvxtiuMwx3w@public.gmane.org>
> Fixes: e056a1b5b67b "(mmc: queue: let host controllers specify maximum discard timeout")
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> If this makes sense, I wonder if it should be Cc: stable?
> ---
>  drivers/mmc/core/core.c | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 57a2b403bf8e..dd793cf4ef46 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -2150,16 +2150,13 @@ static unsigned int mmc_do_calc_max_discard(struct mmc_card *card,
>  	if (!qty)
>  		return 0;
>  
> -	if (qty == 1)
> -		return 1;
> -
>  	/* Convert qty to sectors */
>  	if (card->erase_shift)
> -		max_discard = --qty << card->erase_shift;
> +		max_discard = qty << card->erase_shift;
>  	else if (mmc_card_sd(card))
>  		max_discard = qty;
>  	else
> -		max_discard = --qty * card->erase_size;
> +		max_discard = qty * card->erase_size;
>  
>  	return max_discard;
>  }
> 

The quantity is decreased by 1 to account for the fact that the erase can
cross the boundary between 1 erase block and another. i.e. even though the
size is 1 erase block it touches 2 erase blocks.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] mmc: core: don't decrement qty when calculating max_discard
       [not found]     ` <52B1822F.8080404-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
@ 2013-12-18 16:36       ` Stephen Warren
  0 siblings, 0 replies; 4+ messages in thread
From: Stephen Warren @ 2013-12-18 16:36 UTC (permalink / raw)
  To: Adrian Hunter
  Cc: Chris Ball, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA, Stephen Warren, Dong Aisheng,
	Ulf Hansson, Vladimir Zapolskiy

On 12/18/2013 04:08 AM, Adrian Hunter wrote:
> On 17/12/13 20:02, Stephen Warren wrote:
>> From: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>
>> In mmc_do_calc_max_discard(), if any value has been assigned to qty,
>> that value must have passed the timeout checks in the loop. Hence,
>> qty is the maximum number of erase blocks that fit within the timeout,
>> not the first value that does not fit into the timeout. In turn, this
>> means we don't need any special case for (qty == 1); any value of qty
>> needs to be multiplied by the card's erase shift, and we don't need to
>> decrement qty before doing so.
>>
>> Without this patch, on the NVIDIA Tegra Cardhu board, the loops result
>> in qty == 1, which is immediately returned. This causes discard to
>> operate a single sector at a time, which is chronically slow. With this
>> patch in place, discard operates a single erase block at a time, which
>> is reasonably fast.
...
> The quantity is decreased by 1 to account for the fact that the erase can
> cross the boundary between 1 erase block and another. i.e. even though the
> size is 1 erase block it touches 2 erase blocks.

Don't erases have to be aligned to the erase block alignment; surely
that's what the eMMC's preferred erase alignment is all about?

If that isn't the case, a comment in the code would be extremely useful...

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-12-18 16:36 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-17 18:02 [PATCH] mmc: core: don't decrement qty when calculating max_discard Stephen Warren
2013-12-18 10:32 ` Ulf Hansson
     [not found] ` <1387303344-11802-1-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-12-18 11:08   ` Adrian Hunter
     [not found]     ` <52B1822F.8080404-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2013-12-18 16:36       ` Stephen Warren

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).