All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa@the-dreams.de>
To: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: "ulf.hansson@linaro.org" <ulf.hansson@linaro.org>,
	"wsa+renesas@sang-engineering.com"
	<wsa+renesas@sang-engineering.com>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"linux-renesas-soc@vger.kernel.org" 
	<linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] mmc: renesas_sdhi: use multiple segments if possible
Date: Mon, 13 May 2019 15:54:20 +0200	[thread overview]
Message-ID: <20190513135420.GB20443@kunai> (raw)
In-Reply-To: <OSBPR01MB3174B39C9BE0A725D4945D78D80F0@OSBPR01MB3174.jpnprd01.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]

Hi Shimoda-san,

> > > That also means, for the sys-dmac and Gen2, we then use 512 for the
> > > IOMMU case and 32 (default TMIO value) for the non IOMMU case. My
> > > understanding is that SYS DMAC can handle 512 in both cases. Maybe it
> > > makes sense then to make an incremental patch setting the max_segs value
> > > explicitly to 512 in the sys-dmac driver for Gen2?
> > 
> > I also think SYS DMAC can handle 512 segments. However, I'm not sure
> > it can improve the performance or not though. Anyway, an incremental patch
> > makes sense if needed, I think.
> 
> I measured the performance on R-Car H2 Lager. It seems 512 segments improve
> the sequential input to 5%. May I make an incremental patch on the patch series?
> What do you think?

Cool! I didn't expect that much of a performance improvement. My main
concern was understandable code because there was no "real reason" that
we once use 32 and once 512.

But if it causes even a performance improvement, even better :)

Yes, an incremental patch is a good idea.

Thanks for the work,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2019-05-13 13:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-13  4:29 [PATCH v2 0/2] mmc: renesas_sdhi: improve performance by using IOMMU Yoshihiro Shimoda
2019-05-13  4:29 ` [PATCH v2 1/2] mmc: tmio: No memory size limitation if runs on IOMMU Yoshihiro Shimoda
2019-05-13  4:29 ` [PATCH v2 2/2] mmc: renesas_sdhi: use multiple segments if possible Yoshihiro Shimoda
2019-05-13  9:00   ` Wolfram Sang
2019-05-13  9:46     ` Yoshihiro Shimoda
2019-05-13 11:34       ` Yoshihiro Shimoda
2019-05-13 13:54         ` Wolfram Sang [this message]
2019-05-14  6:05       ` Yoshihiro Shimoda
2019-05-21 21:57         ` Wolfram Sang
2019-05-22  5:11           ` Yoshihiro Shimoda

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=20190513135420.GB20443@kunai \
    --to=wsa@the-dreams.de \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=wsa+renesas@sang-engineering.com \
    --cc=yoshihiro.shimoda.uh@renesas.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 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.