From: Stephen Warren <swarren@wwwdotorg.org>
To: Chris Ball <cjb@laptop.org>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>
Subject: max_discard anomaly on certain Sandisk eMMC
Date: Fri, 13 Dec 2013 15:43:46 -0700 [thread overview]
Message-ID: <52AB8DA2.9000001@wwwdotorg.org> (raw)
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.
For almost all my other eMMC devices, either:
* Both arguments to mmc_do_calc_max_discard() yield zero. Hence, the
discard IOCTL is not supported.
* Both arguments to mmc_do_calc_max_discard() yield some reasonable
large value. Hence, the discard IOCTL executes reasonably quickly.
Do you think that TRIM_ARG result is expected, or is the eMMC firmware
simply buggy?
If I modify mmc_calc_max_discard() to simply ignore the TRIM_ARG result
and always use the ERASE_ARG result, I see no errors when executing
discard operations from either mke2fs, or from the blkdiscard utility. I
have no idea if the discard operation is doing anything useful though.
As an aside, another eMMC device (with same manfid/oemid/name) I have
returns the same 1 for TRIM_ARG, but returns 0 for ERASE_ARG, and hence
discard is disabled, so I don't see this problem:
[ 1.835747] MMC_DISCARD_ARG max_discard 1
[ 1.839779] MMC_ERASE_ARG max_discard 0
[ 1.843791] MMC_TRIM_ARG max_discard 1
To solve my slow discard operations, I'm tempted to modify
mmc_calc_max_discard() as follows:
if (max_discard == 1)
max_discard = 0;
... but I'm not sure if that would be seen as a regression, since it'd
disable the discard operation completely on theoretically working (but
perhaps practically useless) systems.
Alternatively, perhaps I should replace:
if (mmc_can_trim(card)) {
max_trim = mmc_do_calc_max_discard(card, MMC_TRIM_ARG);
if (max_trim < max_discard)
max_discard = max_trim;
with:
if (mmc_can_trim(card)) {
max_trim = mmc_do_calc_max_discard(card, MMC_TRIM_ARG);
if (max_trim > 1 && max_trim < max_discard)
max_discard = max_trim;
Alternatively, should I install a quirk for the specific eMMC device,
which guards one of the changes above, or completely ignores the
TRIM_ARG result?
The eMMC device is question is:
manfid = 0x45
oemid = 0x100
name = SEM16G
Strangely, this is apparently a Sandisk eMMC device, yet there already
exist some quirks for a set of similarly named Sandisk devices, yet they
are triggered by manfid == 2, not 0x45. I'm not sure why Sandisk uses
two separate manufacturer IDs...
next reply other threads:[~2013-12-13 22:43 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-13 22:43 Stephen Warren [this message]
2013-12-16 23:18 ` max_discard anomaly on certain Sandisk eMMC 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
[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=52AB8DA2.9000001@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=cjb@laptop.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-tegra@vger.kernel.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).