From: Sascha Hauer <s.hauer@pengutronix.de>
To: Ahmad Fatoum <a.fatoum@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 1/2] mci: core: import Linux logic for higher preferred erase size
Date: Mon, 17 Feb 2025 11:53:42 +0100 [thread overview]
Message-ID: <Z7MVNjkJiDazmLpc@pengutronix.de> (raw)
In-Reply-To: <20250214094850.2847143-1-a.fatoum@pengutronix.de>
On Fri, Feb 14, 2025 at 10:48:49AM +0100, Ahmad Fatoum wrote:
> As a comment in the file notes, doing too small a granularity for erases
> has considerable effect on performance:
>
> > Example Samsung eMMC 8GTF4:
> >
> > time erase /dev/mmc2.part_of_512m # 1024 trims
> > time: 2849ms
> >
> > time erase /dev/mmc2.part_of_512m # single trim
> > time: 56ms
>
> This was deemed acceptable at first, because 3 seconds is still
> tolerable.
>
> On a SkyHigh S40004, an erase of the whole 3728 MiB ended up
> taking longer than 400s in barebox, but only 4s in Linux, which
> dwarfs the time actually needed for writing.
>
> Linux has some rather complicated logic to compute a higher erase size
> granularity, which still fits in the max busy timeout that a controller
> may require. Until that's support in barebox, we import a simpler
> heuristic that Linux uses to compute
>
> /sys/class/mmc_host/*/*/preferred_erase_size
>
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> ---
> drivers/mci/mci-core.c | 105 ++++++++++++++++++++++++++---------------
> include/mci.h | 1 +
> 2 files changed, 69 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/mci/mci-core.c b/drivers/mci/mci-core.c
> index cc3c6fba3653..6d55eb8305b9 100644
> --- a/drivers/mci/mci-core.c
> +++ b/drivers/mci/mci-core.c
> @@ -1774,6 +1774,70 @@ static int mci_startup_mmc(struct mci *mci)
> return ret >= MMC_BUS_WIDTH_1 ? 0 : ret;
> }
>
> +static void mci_init_erase(struct mci *card)
> +{
> + unsigned int sz;
> +
> + if (!IS_ENABLED(CONFIG_MCI_ERASE))
> + return;
> +
> + /* TODO: While it's possible to clear many erase groups at once
> + * and it greatly improves throughput, drivers need adjustment:
> + *
> + * Many drivers hardcode a maximal wait time before aborting
> + * the wait for R1b and returning -ETIMEDOUT. With long
> + * erases/trims, we are bound to run into this timeout, so for now
> + * we just split into sufficiently small erases that are unlikely
> + * to trigger the timeout.
> + *
> + * What Linux does and what we should be doing in barebox is:
> + *
> + * - add a struct mci_cmd::busy_timeout member that drivers should
> + * use instead of hardcoding their own timeout delay. The busy
> + * timeout length can be calculated by the MCI core after
> + * consulting the appropriate CSD/EXT_CSD/SSR registers.
> + *
> + * - add a struct mci_host::max_busy_timeout member, where drivers
> + * can indicate the maximum timeout they are able to support.
> + * The MCI core will never set a busy_timeout that exceeds this
> + * value.
> + *
> + * Example Samsung eMMC 8GTF4:
> + *
> + * time erase /dev/mmc2.part_of_512m # 1024 trims
> + * time: 2849ms
> + *
> + * time erase /dev/mmc2.part_of_512m # single trim
> + * time: 56ms
> + */
> + if (IS_SD(card) && card->ssr.au) {
> + card->pref_erase = card->ssr.au;
> + } else if (card->erase_grp_size) {
> + sz = card->capacity >> 11;
> + if (sz < 128)
> + card->pref_erase = 512 * 1024 / 512;
> + else if (sz < 512)
> + card->pref_erase = 1024 * 1024 / 512;
> + else if (sz < 1024)
> + card->pref_erase = 2 * 1024 * 1024 / 512;
> + else
> + card->pref_erase = 4 * 1024 * 1024 / 512;
card->capacity is in bytes, so you are falling into the last case for
cards bigger than 512Kib. Did you mean to right shift by 21 or even 31
instead?
I would prefer using SZ_* and SECTOR_SIZE/SHIFT defines to make this more
readable.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
next prev parent reply other threads:[~2025-02-17 10:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-14 9:48 [PATCH 1/2] mci: core: import Linux logic for higher preferred erase size Ahmad Fatoum
2025-02-14 9:48 ` [PATCH 2/2] mci: core: reset ERASE_GRP_DEF on startup Ahmad Fatoum
2025-02-17 10:53 ` Sascha Hauer [this message]
2025-02-17 11:36 ` [PATCH 1/2] mci: core: import Linux logic for higher preferred erase size Ahmad Fatoum
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=Z7MVNjkJiDazmLpc@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.