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 16:10:42 +0100 [thread overview]
Message-ID: <20191210151042.pkmavrxwlry3525t@pengutronix.de> (raw)
In-Reply-To: <CAFfN3gV-kAhDE6=EBJetWT0+T8hgq5tUXAn0qzwK2Q7c8-wsUQ@mail.gmail.com>
Hi Hubert,
On Tue, Dec 10, 2019 at 03:44:52PM +0100, Hubert Feurstein wrote:
> Hi,
>
> I've updated barebox for our custom platform from v2015.06.0 to
> v2019.12.0. With the new version I have noticed a much worse write
> performance onto the onboard eMMC.
>
> With v2015.06.0 the indicated progress of the copy command is very
> smooth. Calling "cp -v /dev/zero /dev/mmc3.root" takes about 80
> seconds for 256MB. But with v2019.12.0 the progress is very bumpy and
> the copy takes about 280 seconds.
>
> I've tracked this down to this commit which destroys the performance:
> "block: Adjust cache sizes" (b6fef20c1215c6ef0004f6af4a9c4b77af51dc43)
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.
The barebox block layer is quite simple. It always handles data in chunks of
a hardcoded size. For a high throughput these should be large as this increases
the buffer size we can write in the MMC controller in one go. Increasing the
size is bad for filesystems though, as for each small block a fs wants
to read at minimum a whole chunk must be read, or for write,
read-modified-written.
I remember I once tried to make the caching more intelligent. It seems I didn't
even get far enough to store a branch in my working copy :(
I just saw that in block_op_write() we must first read any partially
written chunk, then modify it and write it back. Only full chunks can be
written without reading them first. This means we should gain
performance when we enter block_op_write() with only full chunks. 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?
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 15:10 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 [this message]
2019-12-10 15:43 ` Hubert Feurstein
2019-12-10 16:18 ` Sascha Hauer
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=20191210151042.pkmavrxwlry3525t@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