max_discard anomaly on certain Sandisk eMMC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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...
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux