linux-tegra.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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...

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