LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Renius Chen <reniuschengl@gmail.com>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ben Chuang <Ben.Chuang@genesyslogic.com.tw>
Subject: Re: [PATCH] [v2] mmc: sdhci-pci-gli: Improve Random 4K Read Performance of GL9763E
Date: Mon, 19 Jul 2021 17:26:14 +0800	[thread overview]
Message-ID: <CAJU4x8u+BtU5iUna0tSws9rfUTJWfHZ21jteB5nk8e_2iMJgNg@mail.gmail.com> (raw)
In-Reply-To: <02c26834-f16e-e1c7-9ea9-36414d1c4403@intel.com>

Adrian Hunter <adrian.hunter@intel.com> 於 2021年7月16日 週五 下午6:27寫道:
>
> On 14/07/21 5:15 am, Renius Chen wrote:
> > Hi Adrain,
> >
> > What do you think of this patch?
> > Or do you have any ideas or suggestions about the modification for
> > Ulf's comments?
>
> Perhaps try to define your power management requirements in terms of
> latencies instead of request size, and then take the issue to the
> power management mailing list and power management maintainers for
> suggestions.  You will probably need to point out why runtime PM doesn't
> met your requirements.
>

Hi Adrain,


Thanks for your advice.

Our purpose is only to improve the performance of 4K reads, and we
hope that it doesn't affect any other use cases. If we look into the
latencies, it may affect not only 4K reads but also some other use
cases.

Behaviors of ASPM is controlled by circuits of hardware. Drivers only
enable or disable ASPM or set some parameters for ASPM, and are not
able to know when the device enters or exits the L0s/L1 state. So the
PM part of drivers may not suit this case.

This patch could be simply divided into two parts:
1. Monitor requests.
2. Set a vendor specific register of GL9763e.

The part 2 is no problems we think. And Ulf thinks that the behaviors
of part 1 should not be implemented in sdhci-pci-gli.c. Do you have
any suggestions on where we can implement the monitoring?

Thank you.


Best regards,

Renius

> >
> > Thank you.
> >
> >
> > Best regards,
> >
> > Renius
> >
> > Renius Chen <reniuschengl@gmail.com> 於 2021年7月7日 週三 下午9:49寫道:
> >>
> >> Ulf Hansson <ulf.hansson@linaro.org> 於 2021年7月7日 週三 下午8:16寫道:
> >>>
> >>> [...]
> >>>
> >>>>
> >>>> Thanks, I understand what you mean.
> >>>>
> >>>> I simply searched for the keyword "MMC_READ_MULTIPLE_BLOCK" in the
> >>>> drivers/mmc/host folder, and found that in some SD/MMC host controller
> >>>> driver codes such as alcor.c, cavium.c, ...etc, there are also
> >>>> behaviors for monitoring the request in their driver. What's the
> >>>> difference between theirs and ours?
> >>>
> >>> Those checks are there to allow the HWs to be supported properly.
> >>>
> >>>>
> >>>> And if the code that monitors the requstes does not belong the driver,
> >>>> where should I implement the code and how to add some functions only
> >>>> for GL9763e in that place, in your opinion?
> >>>
> >>> Honestly, I am not sure what suits your use case best.
> >>>
> >>> So far we have used runtime PM with a default auto suspend timeout, in
> >>> combination with dev PM Qos. In other words, run as fast as possible
> >>> to complete the requests in the queue then go back to idle and enter a
> >>> low power state. Clearly, that seems not to be sufficient for your use
> >>> case, sorry.
> >>>
> >> Yes, the runtime PM, auto suspend, and PM Qos are all about the
> >> suspend/resume behaviors of the system or related to power states such
> >> as D0/D3 of the device. But these are totally different from the ASPM
> >> L0s/L1 for link states. Entering/exiting the ASPM is pure hardware
> >> behavior on the link layer and is not handled by any codes in
> >> drivers/mmc/core or drivers/mmc/host. We'd like to try to modify the
> >> patch by your opinions, but we are also confused about what or where
> >> suits our use case best. So we wonder how to start the modification
> >> and may need some suggestions to deal with the work, sorry.
> >>
> >> Thank you.
> >>
> >>
> >> Best regards,
> >>
> >> Renius
> >>
> >>
> >>> Kind regards
> >>> Uffe
>

  reply	other threads:[~2021-07-19  9:26 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-05  9:00 Renius Chen
2021-07-05 10:02 ` Ulf Hansson
2021-07-05 10:59   ` Renius Chen
2021-07-05 12:50     ` Ulf Hansson
2021-07-05 15:09       ` Renius Chen
2021-07-06  9:16         ` Ulf Hansson
2021-07-06  9:54           ` Renius Chen
2021-07-06 10:08             ` Ulf Hansson
2021-07-06 10:56               ` Renius Chen
2021-07-07 12:15                 ` Ulf Hansson
2021-07-07 13:49                   ` Renius Chen
2021-07-14  2:15                     ` Renius Chen
2021-07-16 10:27                       ` Adrian Hunter
2021-07-19  9:26                         ` Renius Chen [this message]
2021-08-04  6:27                           ` Adrian Hunter
2021-08-10  4:23                             ` Renius Chen
2021-08-17 10:30                               ` Renius Chen

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=CAJU4x8u+BtU5iUna0tSws9rfUTJWfHZ21jteB5nk8e_2iMJgNg@mail.gmail.com \
    --to=reniuschengl@gmail.com \
    --cc=Ben.Chuang@genesyslogic.com.tw \
    --cc=adrian.hunter@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=ulf.hansson@linaro.org \
    --subject='Re: [PATCH] [v2] mmc: sdhci-pci-gli: Improve Random 4K Read Performance of GL9763E' \
    /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

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).