All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Dong Aisheng <dongas86-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Chris Ball <cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org>,
	"linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: max_discard anomaly on certain Sandisk eMMC
Date: Tue, 17 Dec 2013 10:27:23 -0700	[thread overview]
Message-ID: <52B0897B.5010700@wwwdotorg.org> (raw)
In-Reply-To: <CAA+hA=R3wnbuJrJQhfG9PQEHrwE9nrwg_+xSpyXryOeM2Wtwcw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 12/17/2013 02:25 AM, Dong Aisheng wrote:
> Hi Stephen,
> 
> On Sat, Dec 14, 2013 at 6:43 AM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:
>> On one of my eMMC devices, I see the following results from calling
>> mmc_do_calc_max_discard() with various parameters:
>>
>> [    3.057263] MMC_DISCARD_ARG max_discard 1
>> [    3.057266] MMC_ERASE_ARG   max_discard 4096
>> [    3.057267] MMC_TRIM_ARG    max_discard 1
>>
>> This causes mmc_calc_max_discard() to return 1, which makes the discard
>> IOCTL extremely slow.
>>
> 
> IMX met the similar issue.
> http://www.spinics.net/lists/linux-mmc/msg23375.html
> It's caused by the max_discard_to supported by host is too small.
> 
> I submitted the fix patches:
> http://www.spinics.net/lists/arm-kernel/msg294924.html
> Please see if it helps for you, especially patch #5.
> It could increase the max_discard_to if Tegra has same problem.

Thanks for the pointer!

Yes, Tegra has SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK set, and has a max
clock of 208MHz specified in HW, yet we only run the HW at 48MHz
upstream, since we haven't actually implemented any of the
advanced/faster transfer rates yet. Hence that patch does avoid/solve
the issue on 2 of my boards.

However, the patch doesn't solve the problem on 2 other boards, since
the eMMC device on those boards specifies a much larger timeout, which
still causes max_discard to be set to 0. It sounds like the real
solution is what was discussed elsewhere in this thread; to use command
polling for erases?

Even on the boards where your patch solves the problem, isn't it just a
temporary measure; as soon as we upstream the changes to enable the
faster transfer modes, we'll have a faster SDCLK, and hence again be
limited in the discard size, perhaps down to a single sector again.

(Incidentally, I think the code should be limiting to a single erase
block, not a single sector. I'll send a separate patch to fix that, and
Cc everyone here).

  parent reply	other threads:[~2013-12-17 17:27 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-13 22:43 max_discard anomaly on certain Sandisk eMMC Stephen Warren
2013-12-16 23:18 ` Stephen Warren
2013-12-17  8:17   ` Adrian Hunter
     [not found]     ` <52B008AB.7060909-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2013-12-17  9:40       ` Dong Aisheng
2013-12-17  9:45         ` Vladimir Zapolskiy
2013-12-17 10:04       ` Ulf Hansson
2013-12-17 11:05         ` Dong Aisheng
2013-12-17 12:33           ` Ulf Hansson
     [not found]             ` <CAPDyKFpGpWJRz6AFNqb2AqQMoTuywwZz5Ekq5rc9kboYTGFg7A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-12-17 12:44               ` Ulf Hansson
2013-12-18  3:11               ` Dong Aisheng
     [not found]         ` <CAPDyKFooKY7nyOdLxQS-u9oC_pZL3V8pH5kixLgQpUkPG=kqKw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-12-17 11:20           ` Adrian Hunter
     [not found]             ` <52B03373.3000505-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2013-12-17 12:25               ` Ulf Hansson
2013-12-17 13:14           ` Vladimir Zapolskiy
     [not found] ` <52AB8DA2.9000001-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-12-17  9:25   ` Dong Aisheng
     [not found]     ` <CAA+hA=R3wnbuJrJQhfG9PQEHrwE9nrwg_+xSpyXryOeM2Wtwcw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-12-17 17:27       ` Stephen Warren [this message]
     [not found]         ` <52B0897B.5010700-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-12-18  3:32           ` Dong Aisheng
     [not found]             ` <CAA+hA=Rm1b_ah1uTyps71BLjturJXDHKyWTgiU+z2ELYZKSAWw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-12-18 18:42               ` Stephen Warren

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=52B0897B.5010700@wwwdotorg.org \
    --to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
    --cc=cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org \
    --cc=dongas86-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.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 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.