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