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