From: Ulf Hansson <ulf.hansson@linaro.org>
To: Ricky WU <ricky_wu@realtek.com>
Cc: "tommyhebb@gmail.com" <tommyhebb@gmail.com>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3] mmc: rtsx: improve performance for multi block rw
Date: Tue, 17 Oct 2023 23:28:56 +0200 [thread overview]
Message-ID: <CAPDyKFpeirjA4QmCiqnu4MxN8Yph6d0GiyA95pcmOBRYf8ywSg@mail.gmail.com> (raw)
In-Reply-To: <5752164983174ca68a669c241e7ef436@realtek.com>
On Fri, 13 Oct 2023 at 04:27, Ricky WU <ricky_wu@realtek.com> wrote:
>
> > On Wed, 11 Oct 2023 at 07:36, Ricky WU <ricky_wu@realtek.com> wrote:
> > >
> > > Hi Ulf Hansson,
> > >
> > > Can I know what is this patch status or has some concern on this patch?
> >
> > Didn't you read my earlier replies?
> >
>
> Are you talking about BFQ for testing speed?
> Because we tested the Read/Write speed are better than before and our customer that uses our reader on their product also tested the Read/Write speed, they want us to push this patch on
It's certainly a very positive thing that your target is to upstream
solutions that improve performance. We all appreciate this!
In this regard, I believe I have tried to guide you on how to move
forward with this. This particular optimization doesn't belong in an
mmc host driver, but rather at the common upper block device driver
layer, such that it can benefit more than one particular mmc host
driver.
I fully understand that making that kind of improvement is way more
difficult and requires in-depth analysis to understand what is
happening on those layers too. On the other hand it could be something
that may benefit a lot of devices/platforms. Unfortunately, I am
currently not in a position where I have the bandwidth to dive deeper
into this.
If you decide to pursue your investigations, I think we need to
involve the experts from the common block community (linux-block
mailing list) to get their advice.
So to be clear, I am not going to apply $subject patch - or anything
similar to an mmc host driver.
[...]
Kind regards
Uffe
next prev parent reply other threads:[~2023-10-17 21:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-21 12:24 [PATCH v3] mmc: rtsx: improve performance for multi block rw Ricky WU
2021-12-21 12:51 ` Ulf Hansson
2021-12-23 10:26 ` Ricky WU
2021-12-23 10:37 ` Ulf Hansson
2021-12-24 7:23 ` Ricky WU
2021-12-28 14:04 ` Ulf Hansson
2021-12-29 12:39 ` Ricky WU
2022-02-07 11:11 ` Ulf Hansson
2022-02-10 6:43 ` Ricky WU
2022-02-10 14:56 ` Ulf Hansson
2023-10-11 5:36 ` Ricky WU
2023-10-12 13:40 ` Ulf Hansson
2023-10-13 2:27 ` Ricky WU
2023-10-17 21:28 ` Ulf Hansson [this message]
2023-10-25 10:30 ` Ricky WU
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=CAPDyKFpeirjA4QmCiqnu4MxN8Yph6d0GiyA95pcmOBRYf8ywSg@mail.gmail.com \
--to=ulf.hansson@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=ricky_wu@realtek.com \
--cc=tommyhebb@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;
as well as URLs for NNTP newsgroup(s).