From: "Christian Löhle" <CLoehle@hyperstone.com>
To: Wenchao Chen <wenchao.chen666@gmail.com>,
"ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
"adrian.hunter@intel.com" <adrian.hunter@intel.com>,
"orsonzhai@gmail.com" <orsonzhai@gmail.com>,
"baolin.wang@linux.alibaba.com" <baolin.wang@linux.alibaba.com>,
"zhang.lyra@gmail.com" <zhang.lyra@gmail.com>,
"axboe@kernel.dk" <axboe@kernel.dk>,
"avri.altman@wdc.com" <avri.altman@wdc.com>,
"kch@nvidia.com" <kch@nvidia.com>
Cc: "vincent.whitchurch@axis.com" <vincent.whitchurch@axis.com>,
"bigeasy@linutronix.de" <bigeasy@linutronix.de>,
"s.shtylyov@omp.ru" <s.shtylyov@omp.ru>,
"michael@allwinnertech.com" <michael@allwinnertech.com>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"megoo.tang@gmail.com" <megoo.tang@gmail.com>,
"lzx.stg@gmail.com" <lzx.stg@gmail.com>
Subject: RE: [PATCH V2 0/2] mmc: block: Support Host to control FUA
Date: Fri, 21 Oct 2022 16:10:07 +0000 [thread overview]
Message-ID: <e7858446b9604b59b8270f181a1410ef@hyperstone.com> (raw)
In-Reply-To: <20221021073025.18831-1-wenchao.chen666@gmail.com>
> These patches[1] supports the host to turn off FUA.
>
> About FUA, roughly deal with the following two parts:
> 1) FUA(Forced Unit Access):
> - The REQ_FUA flag can be OR ed into the r/w flags of a bio submitted from the
> filesystem and will make sure that I/O completion for this request is only
> signaled after the data has been committed to non-volatile storage.
>
> 2) In emmc, FUA is represented as Reliable write. code show as below:
> static void mmc_blk_data_prep(struct mmc_queue *mq, struct mmc_queue_req *mqrq,
> int recovery_mode, bool *do_rel_wr_p, bool *do_data_tag_p) {
> ...
> /*
> * Reliable writes are used to implement Forced Unit Access and
> * are supported only on MMCs.
> */
> do_rel_wr = (req->cmd_flags & REQ_FUA) &&
> rq_data_dir(req) == WRITE &&
> (md->flags & MMC_BLK_REL_WR);
> ...
> }
So reliable writes are only issed when FUA flag is set, so as it should be?
>
> Patch structure
> ===============
> patch#1: for block
> patch#2: for sdhci-sprd
>
> Tests
> =====
> Ran 'AndroBench' to evaluate the performance:
> 1. fua_disable = 1
> /sys/block/mmcblk0/queue # cat fua 0
> I tested 5 times for each case and output a average speed.
>
> 1) Sequential read:
> Speed: 266.8MiB/s, 265.1MiB/s, 262.9MiB/s, 268.7MiB/s, 265.2MiB/s Average speed: 265.74MiB/s
>
> 2) Random read:
> Speed: 98.75MiB/s, 98.7MiB/s, 98.5MiB/s, 99.4MiB/s, 98.7MiB/s Average speed: 98.81MiB/s
>
> 3) Sequential write:
> Speed: 199.94MiB/s, 199.1MiB/s, 205.5MiB/s, 206.5MiB/s, 191.5MiB/s Average speed: 200.5MiB/s
>
> 4) Random write:
> Speed: 68.6MiB/s, 71.8MiB/s, 77.1MiB/s, 64.8MiB/s, 69.3MiB/s Average speed: 70.32MiB/s
>
Unless there is something special / wrong with sdhci-sprd (unlikely? Its just a flag) or your eMMC (maybe more likely?)
then Id expect this or similar performance degradation for any host controller and eMMC.
I can redo some measurement if you provide your workload.
But I'd say if you don’t want to pay the price of reliable write then make sure to not issue them, by not issuing
FUA?
Maybe I'm misunderstanding, but why would the host controller driver control FUA?
> 2. fua_disable = 0 (default 0)
> /sys/block/mmcblk0/queue # cat fua 1
> I tested 5 times for each case and output a average speed.
>
> 1) Sequential read:
> Speed: 259.3MiB/s, 258.8MiB/s, 258.2MiB/s, 259.5MiB/s, 253.5MiB/s Average speed: 257.86MiB/s
>
> 2) Random read:
> Speed: 98.9MiB/s, 101MiB/s, 101MiB/s, 99MiB/s, 101.1MiB/s Average speed: 100.2MiB/s
>
> 3) Sequential write:
> Speed: 153.7MiB/s, 146.2MiB/s, 151.2MiB/s, 148.8MiB/s, 147.5MiB/s Average speed: 149.48MiB/s
>
> 4) Random write:
> Speed: 12.9MiB/s, 12.3MiB/s, 12.6MiB/s, 12.8MiB/s, 12.8MiB/s Average speed: 12.68MiB/s
>
> According to the above data, disable FUA (fua_disable = 1) improves the
> performance:
> 1)Sequential read improved by 3%.
> 2)Random read were down 1%.
> 3)Sequential write improved by 34%.
> 4)Random write improved by 454%.
> Therefore, it is recommended to support the host to control FUA.
>
>
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:[~2022-10-21 16:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-21 7:30 [PATCH V2 0/2] mmc: block: Support Host to control FUA Wenchao Chen
2022-10-21 7:30 ` [PATCH V2 1/2] " Wenchao Chen
2022-10-21 7:53 ` Avri Altman
2022-10-21 8:47 ` Wenchao Chen
2022-10-21 9:37 ` Avri Altman
2022-10-21 7:30 ` [PATCH V2 2/2] mmc: sdhci-sprd: enable fua_disable for SPRDSDHCI Wenchao Chen
2022-10-21 9:42 ` [PATCH V2 0/2] mmc: block: Support Host to control FUA Avri Altman
2022-10-21 15:50 ` Adrian Hunter
2022-11-11 7:58 ` Wenchao Chen
2022-11-11 11:34 ` Ulf Hansson
2022-11-11 12:04 ` Ulf Hansson
2023-02-09 14:50 ` Ulf Hansson
2023-02-13 8:21 ` Wenchao Chen
2023-02-15 15:13 ` Ulf Hansson
2022-11-18 10:11 ` Adrian Hunter
2022-11-18 10:54 ` Wenchao Chen
2022-11-18 11:26 ` Adrian Hunter
2022-10-21 16:10 ` Christian Löhle [this message]
2022-10-21 16:32 ` Christian Löhle
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=e7858446b9604b59b8270f181a1410ef@hyperstone.com \
--to=cloehle@hyperstone.com \
--cc=adrian.hunter@intel.com \
--cc=avri.altman@wdc.com \
--cc=axboe@kernel.dk \
--cc=baolin.wang@linux.alibaba.com \
--cc=bigeasy@linutronix.de \
--cc=kch@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=lzx.stg@gmail.com \
--cc=megoo.tang@gmail.com \
--cc=michael@allwinnertech.com \
--cc=orsonzhai@gmail.com \
--cc=s.shtylyov@omp.ru \
--cc=ulf.hansson@linaro.org \
--cc=vincent.whitchurch@axis.com \
--cc=wenchao.chen666@gmail.com \
--cc=zhang.lyra@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