From: "Christian Löhle" <CLoehle@hyperstone.com>
To: Ulf Hansson <ulf.hansson@linaro.org>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
Jens Axboe <axboe@kernel.dk>
Cc: Wenchao Chen <wenchao.chen666@gmail.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Avri Altman <avri.altman@wdc.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [RFC PATCH] mmc: core: Disable REQ_FUA if the eMMC supports an internal cache
Date: Thu, 2 Mar 2023 15:07:56 +0000 [thread overview]
Message-ID: <5712c69ae37447c5b576d87b247f5756@hyperstone.com> (raw)
In-Reply-To: <20230302144330.274947-1-ulf.hansson@linaro.org>
> Subject: [RFC PATCH] mmc: core: Disable REQ_FUA if the eMMC supports an internal cache
Hey Uffe,
I may have the setup to play with this.
(Powerfailing eMMC devices)
>
> REQ_FUA is in general supported for eMMC cards, which translates into so called "reliable writes". To support these write operations, the CMD23 (MMC_CAP_CMD23), needs to be supported by the mmc host too, which is common but not always the case.
>
> For some eMMC devices, it has been reported that reliable writes are quite costly, leading to performance degradations.
>
> In a way to improve the situation, let's avoid announcing REQ_FUA support if the eMMC supports an internal cache, as that allows us to rely solely on flush-requests (REQ_OP_FLUSH) instead, which seems to be a lot cheaper.
> Note that, those mmc hosts that lacks CMD23 support are already using this type of configuration, whatever that could mean.
Just note that reliable write is strictly weaker than turning cache off/flushing,
if card loses power during cache off/flush programming / busy, sector-wise atomicity is not mandated by the spec.
(And that is assuming cache off/flush is actually respected by the card as intended by the spec, should some cards be checked?)
Maybe some FS people can also chime in?
Regards,
Christian
Hyperstone GmbH | Reichenaustr. 39a | 78467 Konstanz
Managing Director: Dr. Jan Peter Berns.
Commercial register of local courts: Freiburg HRB381782
next prev parent reply other threads:[~2023-03-02 15:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-02 14:43 [RFC PATCH] mmc: core: Disable REQ_FUA if the eMMC supports an internal cache Ulf Hansson
2023-03-02 15:02 ` Bean Huo
2023-03-03 9:39 ` Avri Altman
2023-03-03 11:03 ` Ulf Hansson
2023-03-03 11:37 ` Avri Altman
2023-03-02 15:07 ` Christian Löhle [this message]
2023-03-03 11:40 ` Christian Löhle
2023-03-03 12:01 ` Ulf Hansson
2023-03-03 14:41 ` Adrian Hunter
2023-03-06 16:09 ` Ulf Hansson
2023-03-07 13:15 ` Adrian Hunter
2023-03-10 13:43 ` Christian Löhle
2023-03-10 14:53 ` Ulf Hansson
2023-03-10 17:06 ` Christian Löhle
2023-03-13 16:56 ` Adrian Hunter
2023-03-14 7:56 ` Ulf Hansson
2023-03-14 8:57 ` Adrian Hunter
2023-03-16 12:12 ` Ulf Hansson
2023-03-16 12:44 ` Adrian Hunter
2023-03-11 8:30 ` Avri Altman
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=5712c69ae37447c5b576d87b247f5756@hyperstone.com \
--to=cloehle@hyperstone.com \
--cc=adrian.hunter@intel.com \
--cc=avri.altman@wdc.com \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=ulf.hansson@linaro.org \
--cc=wenchao.chen666@gmail.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