linux-kernel - RE: [EXT] Re: [PATCH] mmc: sdhci-esdhc-imx: improve imx8mq emmc/sd read performance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
 <PAXPR04MB8574A715E7BEBB67F3B1EEACEDFA2@PAXPR04MB8574.eurprd04.prod.outlook.com>
Date: Tue, 18 Feb 2025 03:09:29 +0000
From: Luke Wang <ziniu.wang_1@....com>
To: Lucas Stach <l.stach@...gutronix.de>, "adrian.hunter@...el.com"
	<adrian.hunter@...el.com>, "ulf.hansson@...aro.org" <ulf.hansson@...aro.org>
CC: "imx@...ts.linux.dev" <imx@...ts.linux.dev>, dl-S32 <S32@....com>,
	"shawnguo@...nel.org" <shawnguo@...nel.org>, "s.hauer@...gutronix.de"
	<s.hauer@...gutronix.de>, "linux-mmc@...r.kernel.org"
	<linux-mmc@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Bough Chen <haibo.chen@....com>,
	"kernel@...gutronix.de" <kernel@...gutronix.de>, "festevam@...il.com"
	<festevam@...il.com>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [EXT] Re: [PATCH] mmc: sdhci-esdhc-imx: improve imx8mq emmc/sd
 read performance

Hi Lucas,

You are right. 
This issue is observed on local kernel. I checked that the local kernel does use a deeper PSCI idle state (power off).
So, the upstream kernel will not be affected by this.

Thank you,
Luke

> -----Original Message-----
> From: Lucas Stach <l.stach@...gutronix.de>
> Sent: Monday, February 17, 2025 7:58 PM
> To: Luke Wang <ziniu.wang_1@....com>; adrian.hunter@...el.com;
> ulf.hansson@...aro.org
> Cc: imx@...ts.linux.dev; dl-S32 <S32@....com>; shawnguo@...nel.org;
> s.hauer@...gutronix.de; linux-mmc@...r.kernel.org; linux-
> kernel@...r.kernel.org; Bough Chen <haibo.chen@....com>;
> kernel@...gutronix.de; festevam@...il.com; linux-arm-
> kernel@...ts.infradead.org
> Subject: [EXT] Re: [PATCH] mmc: sdhci-esdhc-imx: improve imx8mq emmc/sd
> read performance
> 
> [You don't often get email from l.stach@...gutronix.de. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report
> this email' button
> 
> 
> Hi Luke,
> 
> Am Montag, dem 17.02.2025 um 19:06 +0800 schrieb
> ziniu.wang_1@....com:
> > From: Luke Wang <ziniu.wang_1@....com>
> >
> > Compared with kernel 6.1, imx8mq eMMC/SD read performance drops by
> about
> > 30% with kernel 6.6.
> >
> > The eMMC/SD read thread will be put to sleep until the hardware
> completes
> > data transfer. Normally, the read thread will be woken up immediately
> > when the data transfer is completed. However, due to a known ic bug, if
> > imx8mq is in cpuidle, it will take a long time (about 500us) to exit
> > cpuidle. As a result, the read thread cannot immediately read the next
> > data block, affecting the read performance.
> >
> Is this really a problem with the upstream kernel? i.MX8MQ upstream
> does not use the deeper PSCI idle states, but only uses WFI, so I doubt
> that upstream is affected by this issue.
> 
> Regards,
> Lucas
> 
> > Kernel 6.6 uses EEVDF as the new scheduler, which affects cpu scheduling
> > and cpuidle behavior. With kernel 6.6, the cpu which the read thread
> > resides has a greater probability in cpuidle (about 80%), while with
> > kernel 6.1, the probability is only about 20-30%. For other platforms,
> > this does not have a significant impact on read performance because the
> > cpuidle exit time is very short (for example, imx93 is about 60us). But
> > for imx8mq, this results in longer waits for the thread to be woken up
> > while reading eMMC/SD, which drops performance.
> >
> > So for imx8mq, use the ESDHC_FLAG_PMQOS flag to request the cpu
> latency
> > QoS constraint. This can prevent entering cpuidle during data transfer.
> >
> > Signed-off-by: Luke Wang <ziniu.wang_1@....com>
> > ---
> >  drivers/mmc/host/sdhci-esdhc-imx.c | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-
> esdhc-imx.c
> > index ff78a7c6a04c..b3bf9c171d46 100644
> > --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> > +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> > @@ -337,6 +337,15 @@ static struct esdhc_soc_data usdhc_imx8mm_data
> = {
> >       .quirks = SDHCI_QUIRK_NO_LED,
> >  };
> >
> > +static struct esdhc_soc_data usdhc_imx8mq_data = {
> > +     .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
> > +                     | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
> > +                     | ESDHC_FLAG_HS400 | ESDHC_FLAG_PMQOS
> > +                     | ESDHC_FLAG_STATE_LOST_IN_LPMODE
> > +                     | ESDHC_FLAG_BROKEN_AUTO_CMD23,
> > +     .quirks = SDHCI_QUIRK_NO_LED,
> > +};
> > +
> >  struct pltfm_imx_data {
> >       u32 scratchpad;
> >       struct pinctrl *pinctrl;
> > @@ -381,6 +390,7 @@ static const struct of_device_id imx_esdhc_dt_ids[]
> = {
> >       { .compatible = "fsl,imx7ulp-usdhc", .data = &usdhc_imx7ulp_data, },
> >       { .compatible = "fsl,imx8qxp-usdhc", .data = &usdhc_imx8qxp_data, },
> >       { .compatible = "fsl,imx8mm-usdhc", .data = &usdhc_imx8mm_data, },
> > +     { .compatible = "fsl,imx8mq-usdhc", .data = &usdhc_imx8mq_data, },
> >       { .compatible = "fsl,imxrt1050-usdhc", .data =
> &usdhc_imxrt1050_data, },
> >       { .compatible = "nxp,s32g2-usdhc", .data = &usdhc_s32g2_data, },
> >       { /* sentinel */ }