From: Sascha Hauer <s.hauer@pengutronix.de>
To: Hubert Feurstein <h.feurstein@gmail.com>
Cc: barebox@lists.infradead.org
Subject: Re: [BUG] imx6qdl: degraded eMMC write performance
Date: Tue, 10 Dec 2019 17:18:12 +0100 [thread overview]
Message-ID: <20191210161812.t7mf72pdm53odmdn@pengutronix.de> (raw)
In-Reply-To: <CAFfN3gURy6N4F=u-uCUU-sYabvjBUfts2XeKNyJXfBxY1frKYg@mail.gmail.com>
On Tue, Dec 10, 2019 at 04:43:54PM +0100, Hubert Feurstein wrote:
> Hi Sascha,
>
> Am Di., 10. Dez. 2019 um 16:10 Uhr schrieb Sascha Hauer
> <s.hauer@pengutronix.de>:
> [...]
> > Well the commit message says it:
> > | commit b6fef20c1215c6ef0004f6af4a9c4b77af51dc43
> > | Author: Sascha Hauer <s.hauer@pengutronix.de>
> > | Date: Thu Mar 29 13:49:45 2018 +0200
> > |
> > | block: Adjust cache sizes
> > |
> > | Use four times more cache entries and divide the memory for each entry
> > | by four. This lowers the linear read throughput somewhat but increases
> > | the access speed for filesystems.
> Yes, I know. I've read the commit message. But this patch even costs me ~200ms
> in boottime (loading kernel and dts from ext4 root partition).
>
> [...]
> > We could adjust RW_BUF_SIZE (used by copy_file as buffer size) to a full
> > chunk size (16KiB). Does this give you back some lost performance?
> No, changing RW_BUF_SIZE did not help.
And I also see why :-/
block_op_write() works around block sizes (512bytes), not around chunk
sizes. This means we always read before we write. This could probably be
optimized somehow, but this would only speed up the write case you
described in your initial mail. It seems what you are more interested in
is the read performance.
We could make the number of chunks and the chunk size configurable
during runtime. This is less than ideal, but at least we could get a
better performance with manageable effort.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2019-12-10 16:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-10 14:44 Hubert Feurstein
2019-12-10 15:10 ` Sascha Hauer
2019-12-10 15:43 ` Hubert Feurstein
2019-12-10 16:18 ` Sascha Hauer [this message]
2019-12-10 17:46 ` Hubert Feurstein
2019-12-13 13:12 ` Sascha Hauer
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=20191210161812.t7mf72pdm53odmdn@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=h.feurstein@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