From: "Bean Huo (beanhuo)" <beanhuo@micron.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: "linus.walleij@linaro.org" <linus.walleij@linaro.org>,
"shawn.lin@rock-chips.com" <shawn.lin@rock-chips.com>,
"adrian.hunter@intel.com" <adrian.hunter@intel.com>,
"axboe@fb.com" <axboe@fb.com>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Zoltan Szubbocsev (zszubbocsev)" <zszubbocsev@micron.com>
Subject: RE: [PATCH V1] mmc: core: fix still flush cache when eMMC cache off
Date: Fri, 24 Mar 2017 11:16:30 +0000 [thread overview]
Message-ID: <bba6c1dd59ee4b8aad4b1f9929f7caf0@SIWEX5A.sing.micron.com> (raw)
In-Reply-To: <CAPDyKFqNm3cu0MckrOcT1rdt1s6oSFCE72Lz_GyfHZYaqoqAoA@mail.gmail.com>
Hi, Uffe
>>>On 19 March 2017 at 01:45, Bean Huo (beanhuo) <beanhuo@micron.com>
>wrote:
>>>> This patch fixes the issue that mmc_blk_issue_rq still flushes cache
>>>> when eMMC cache has already been off through user space tool, such
>>>> as mmc-utils.
>>>> The reason is that card->ext_csd.cache_ctrl isn't reset.
>>>
>>>First, why do you want to turn of the cache ctrl? Is the eMMC device
>>>having issues with it? Then we should invent a card quirk instead.
>>
>>
>> Why I turn off it? because I did power loss testing and validation, I should
>switch it off and on.
>> When I do some performance and power loss case validation on several
>> Linux release versions, I need to switch off or on cache through user space tool.
>> I can't confirm every user that likes me, But I think at least it is
>> not reasonable to flush eMMC cache, when internal eMMC cache is off.
>
>Ah, I see. Your use-case seems reasonable while validating robustness of the
>eMMC!
>
>>
>>>Second, what errors do you encounter when the mmc core tries to flush
>>>the cache when it has been turned off? Can you please elaborate on this?
>>
>>
>> No error found, but firstly, please think about overhead introduced by
>> useless flush cache, Unless you Don't care this tiny time. second,
>> under the condition of cache off, additional flush cache request still has impact
>>on Internal eMMC logic. I don't know What and how impact, but at least it is
>>really exist.
>
>Got it!
>
>However I still don't like the mmc ioctls API to compensate and deal with all
>"crazy-ness" that user-space may cause. Cache-ctrl is only one case out of many.
Question is that not every Linux-mmc user really understand that shouldn't use "mmc ioctls API
to compensate and deal with all crazy-ness that user-space may cause ".
no matter we like or dislike, Issue is already there; I think that most of eMMC user is now
configuring eMMC through mmc-utils and mmc ioctls. This is a real condition.
Some automotive applications, Cache would not be enabled.
Maybe I am shallow, mmc ioctls likes backdoor that let user access and configure eMMC some feature,
Even not too often. I still suggest to fix this in mmc ioctls, unless mmc iotcls being deleted, and mmc-utils
doesn't support Cache off/on.
Because eMMC internal cache has been disabled, but Linux-mmc still issue flush cache request, this is indeed
Not reasonable. It definitely increases system level overhead.
>I see two viable options to solve your problem.
>1) Extend mmc_test with a new test(s) for cache ctrl and perhaps suspend/resume.
>Isn't this actually exactly what you want?
>2) Extend debugfs to be able to turn cache ctrl on/off.
I can try, but this patch is just to fix mmc ctrls backdoor on eMMC flush cache.
>[...]
>
>Kind regards
>Uffe
>--
>To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of
>a message to majordomo@vger.kernel.org More majordomo info at
>http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2017-03-24 11:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-19 0:45 Bean Huo (beanhuo)
2017-03-20 7:33 ` Shawn Lin
[not found] ` <CGME20170320113503epcas1p1115fcb2a974a38a4133230b5b9013fbb@epcas1p1.samsung.com>
2017-03-20 11:35 ` Bartlomiej Zolnierkiewicz
2017-03-22 17:31 ` Bean Huo (beanhuo)
2017-03-23 10:03 ` Ulf Hansson
2017-03-23 10:45 ` Bean Huo (beanhuo)
2017-03-23 13:10 ` Ulf Hansson
2017-03-24 11:16 ` Bean Huo (beanhuo) [this message]
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=bba6c1dd59ee4b8aad4b1f9929f7caf0@SIWEX5A.sing.micron.com \
--to=beanhuo@micron.com \
--cc=adrian.hunter@intel.com \
--cc=axboe@fb.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=shawn.lin@rock-chips.com \
--cc=ulf.hansson@linaro.org \
--cc=zszubbocsev@micron.com \
/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
all inboxes | Powered by JetHome®