linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ladislav Michl <oss-lists@triops.cz>
To: Linus Walleij <linus.walleij@linaro.org>,
	Robert Richter <rric@kernel.org>
Cc: linux-mmc@vger.kernel.org, linux-mips@vger.kernel.org
Subject: (Octeon) MMC performance degradation due to too many requests
Date: Sun, 6 Aug 2023 13:48:37 +0200	[thread overview]
Message-ID: <ZM+IlctTTQLs7Qg9@lenoch> (raw)

Hi Linus,

let me appologize for walking into dark past :) Here's some more context
for a start:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1691602.html
(note that "OK phew then I'm safe" ;-))

After moving a few Octeon 70XX based boards from vendor based 4.9 kernel
to 6.1 mainline a huge drop of MMC performance was observed.

While running badblocks on 2G partition takes 1min (±5s) and about 35k
interrupts on 4.9, recent kernels need over 3mins and 500k+ interrupts.

How do we get there?
ff4143ccff31 ("MIPS: Octeon: cavium_octeon_defconfig: Enable Octeon MMC")
enabled MMC driver, but left MMC_BLOCK_BOUNCE disabled, although driver
performace depends on it.
c3dccb74be28 ("mmc: core: Delete bounce buffer Kconfig option")
Added MMC_CAP_NO_BOUNCE_BUFF to the caps, based on assumption it should
be there as MMC_BLOCK_BOUNCE is disabled in defconfig
de3ee99b097d ("mmc: Delete bounce buffer handling")
finally removed all bounce buffer handling as almost nothing needs that.

Sadly, 70XX SoC cannot do SG, so it suffers a lot. Strangely enough,
above patches are either authored or suggested by Cavium's employees.

So, given the number of affected SoC and before cooking driver specific
solution, are we sure we indeed do not want some generic one?

While there, you might consider following patch:
-- >8 --
From: Ladislav Michl <ladis@linux-mips.org>
Subject: [PATCH] mmc: cavium: Remove misleading comment

Comment about disabling bounce buffers was added with c3dccb74be28
("mmc: core: Delete bounce buffer Kconfig option") and should be
deleted with de3ee99b097d ("mmc: Delete bounce buffer handling").
For the record, this driver should have never been used
MMC_CAP_NO_BOUNCE_BUFF as it hits performance badly for non SG
capable SoC.

Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Fixes: de3ee99b097d ("mmc: Delete bounce buffer handling")
---
 drivers/mmc/host/cavium.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/mmc/host/cavium.c b/drivers/mmc/host/cavium.c
index b58f003b10a4..71a9f91d2fc6 100644
--- a/drivers/mmc/host/cavium.c
+++ b/drivers/mmc/host/cavium.c
@@ -1032,8 +1032,6 @@ int cvm_mmc_of_slot_probe(struct device *dev, struct cvm_mmc_host *host)
 	 * We only have a 3.3v supply, we cannot support any
 	 * of the UHS modes. We do support the high speed DDR
 	 * modes up to 52MHz.
-	 *
-	 * Disable bounce buffers for max_segs = 1
 	 */
 	mmc->caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
 		     MMC_CAP_CMD23 | MMC_CAP_POWER_OFF_CARD | MMC_CAP_3_3V_DDR;
-- 
2.39.2


             reply	other threads:[~2023-08-06 11:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-06 11:48 Ladislav Michl [this message]
2023-08-06 20:44 ` (Octeon) MMC performance degradation due to too many requests Linus Walleij
2023-08-06 21:03   ` Ladislav Michl
2023-08-11 11:39   ` Ladislav Michl
2023-08-11 12:02     ` Linus Walleij

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=ZM+IlctTTQLs7Qg9@lenoch \
    --to=oss-lists@triops.cz \
    --cc=linus.walleij@linaro.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=rric@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).