Hello,
I thought I'd poke about with the eMMC in the Galaxy S4 which I have
here to see if it supported a sufficient number of AUs to be worth
switching to f2fs (I believe you need 7 simultaneous AUs minimum?).
Had a go at determining AUs, but I don't think I'm seeing any
performance drop-off, but not sure if I'm doing something wrong?
Cheers,
Tim.
root@localhost:/# cd /sys/block/mmcblk0/device/ && grep ^ * 2> /dev/null
caps:0x40080f4e
caps2:0x00031927
cid:110100303136473934b0d49cac223006
csd:d00e00320f5903ffffffffff92400024
date:03/1997
enhanced_area_offset:18446744073709551594
enhanced_area_size:4294967274
erase_size:4194304
erase_type:MMC_CAP_ERASE enabled, type DISCARD, SECURE supportable,
Sanitize enabled
fwdate:0x0000000000000000
fwrev:0x0
hwrev:0x0
manfid:0x000011
name:016G94
oemid:0x0100
preferred_erase_size:4194304
serial:0xd49cac22
smart:0x0000000000000000
type:MMC
uevent:DRIVER=mmcblk
uevent:MMC_TYPE=MMC
uevent:MMC_NAME=016G94
uevent:MODALIAS=mmc:block
root@localhost:/# flashbench -a /dev/block/mmcblk0
align 4294967296 pre 458µs on 523µs post 484µs diff 52.3µs
align 2147483648 pre 445µs on 580µs post 501µs diff 107µs
align 1073741824 pre 436µs on 549µs post 488µs diff 87.2µs
align 536870912 pre 419µs on 475µs post 445µs diff 43.6µs
align 268435456 pre 436µs on 497µs post 453µs diff 52.3µs
align 134217728 pre 471µs on 549µs post 532µs diff 48µs
align 67108864 pre 532µs on 562µs post 541µs diff 26.2µs
align 33554432 pre 510µs on 593µs post 549µs diff 63.2µs
align 16777216 pre 645µs on 724µs post 680µs diff 61µs
align 8388608 pre 637µs on 702µs post 663µs diff 52.3µs
align 4194304 pre 767µs on 859µs post 798µs diff 76.3µs
align 2097152 pre 776µs on 841µs post 802µs diff 52.3µs
align 1048576 pre 772µs on 846µs post 798µs diff 61µs
align 524288 pre 776µs on 824µs post 811µs diff 30.5µs
align 262144 pre 789µs on 793µs post 785µs diff 6.54µs
align 131072 pre 789µs on 802µs post 793µs diff 10.9µs
align 65536 pre 802µs on 802µs post 802µs diff 0ns
align 32768 pre 824µs on 820µs post 793µs diff 10.9µs
root@localhost:~# gdisk -l /dev/block/mmcblk0 | egrep '^(Num| 18)'
Number Start (sector) End (sector) Size Code Name
18 5894728 10134087 2.0 GiB 8300 cache
# since I only want to operate on this partition I'll manually round up
# the start offset of this partition to hit the first erase block (4M
# according to the card) which is in side the start of the partition.
root@localhost:/# flashbench /dev/block/mmcblk0p18 --offset 1798144
--open-au --erasesize=$[4 * 1024 * 1024] --blocksize=$[256 * 1024]
--open-au-nr=2
4MiB 26.8M/s
2MiB 25.8M/s
1MiB 25.1M/s
512KiB 23.5M/s
256KiB 20.5M/s
root@localhost:/# flashbench /dev/block/mmcblk0p18 --offset 1798144
--open-au --erasesize=$[4 * 1024 * 1024] --blocksize=$[256 * 1024]
--open-au-nr=64
4MiB 24.7M/s
2MiB 25.2M/s
1MiB 25.2M/s
512KiB 24.1M/s
256KiB 20M/s
root@localhost:~# flashbench /dev/block/mmcblk0p18 --offset 1798144
--open-au --random --erasesize=$[4 * 1024 * 1024] --blocksize=$[16 *
1024] --open-au-nr=2
4MiB 23.8M/s
2MiB 26.2M/s
1MiB 25M/s
512KiB 24.8M/s
256KiB 19.8M/s
128KiB 15.4M/s
64KiB 11.9M/s
32KiB 13.1M/s
16KiB 9.51M/s
root@localhost:~# flashbench /dev/block/mmcblk0p18 --offset 1798144
--open-au --random --erasesize=$[4 * 1024 * 1024] --blocksize=$[16 *
1024] --open-au-nr=33
4MiB 24.9M/s
2MiB 25.8M/s
1MiB 25.2M/s
512KiB 24.5M/s
256KiB 20M/s
128KiB 15.1M/s
64KiB 11.5M/s
32KiB 12.1M/s
16KiB 8.48M/s
root@localhost:~# flashbench /dev/block/mmcblk0p18 --offset 1798144
--open-au --random --erasesize=$[4 * 1024 * 1024] --blocksize=$[16 *
1024] --open-au-nr=65
4MiB 22.2M/s
2MiB 25.9M/s
1MiB 25.4M/s
512KiB 24.3M/s
256KiB 20.4M/s
128KiB 15.7M/s
64KiB 11.8M/s
32KiB 12.6M/s
16KiB 8.68M/s
root@localhost:~# flashbench /dev/block/mmcblk0p18 --offset 1798144
--open-au --random --erasesize=$[4 * 1024 * 1024] --blocksize=$[16 *
1024] --open-au-nr=1
4MiB 15.8M/s
2MiB 24.1M/s
1MiB 26.4M/s
512KiB 24.3M/s
256KiB 19.3M/s
128KiB 16M/s
64KiB 12M/s
32KiB 13.1M/s
16KiB 9.92M/s
# ... not really sure how to interpret that. Am I wrong in attempting
# to just operate on the partition, with that offset?
"I retain the right to change my mind, as always. Le Linus e mobile."
~ Linus Torvalds
The Linaro 16.12 release is now available for download!
This is probably the last installment of this monthly largely autogenerated email. Fewer and fewer components in Linaro have monthly cycles and with other changes scheduled for 2017 this email has become less than useful.
The releases and snapshot they are based on will continue, but no email about them anymore.
Also: shortest cycle ever!
If you have snow where you live, I’m very jealous. If you live on the southern hemisphere with hot, sunny weather, I’m also very jealous. If you like rain, wind and gloom, come visit me! Enjoy the holidays!
Using the Android-based images
=======================
The Android-based images come in three parts: system, userdata and boot.
These need to be combined to form a complete Android install. For an
explanation of how to do this please see:
http://wiki.linaro.org/Platform/Android/ImageInstallation
If you are interested in getting the source and building these images
yourself please see the following pages:
http://wiki.linaro.org/Platform/Android/GetSourcehttp://wiki.linaro.org/Platform/Android/BuildSource
Using the OpenEmbedded-based images
=======================
With the Linaro provided downloads and with ARM’s Fast Models virtual
platform, you can boot a virtual ARMv8 system and run 64-bit binaries.
For more information please see:
http://www.linaro.org/engineering/armv8
Using the Debian-based images
=======================
The Debian-based images consist of two parts. The first part is a
hardware pack, which can be found under the hwpacks directory and
contains hardware specific packages (such as the kernel and bootloader).
The second part is the rootfs, which is combined with the hardware pack
to create a complete image. For more information on how to create an
image please see:
http://wiki.linaro.org/Platform/DevPlatform/Ubuntu/ImageInstallation
Getting involved
============
More information on Linaro can be found on our websites:
* Homepage:
http://www.linaro.org
* Wiki:
http://wiki.linaro.org
Also subscribe to the important Linaro mailing lists and join our IRC
channels to stay on top of Linaro developments:
* Announcements:
http://lists.linaro.org/mailman/listinfo/linaro-announce
* Development:
http://lists.linaro.org/mailman/listinfo/linaro-dev
* IRC:
#linaro on irc.linaro.org or irc.freenode.net
#linaro-android irc.linaro.org or irc.freenode.net
Known issues with this release
=====================
Bug reports for this release should be filed in Bugzilla (http://bugs.linaro.org) against the
individual packages or projects that are affected.
On behalf of the release team,
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
There's been a long standing request to move git.linaro.org's web UI
over to cgit[1]. We've just deployed a test version at:
https://git.linaro.org/cgit/
We'd like to get people to try out and share any issues they have. Once
we work through issues, we'd like to get rid of the old gitweb interface
and make this the standard web UI to our git servers.
cgit has a bunch of nice features you should enjoy including:
* Significantly faster
* README support, eg: https://git.linaro.org/cgit/arm/vixl.git/about/
* A much cleaner UI (slightly objective opinion)
* Actively used by the best git sites such as git.kernel.org
= FAQ:
Q: The front page is much smaller?
A: I've collapsed many of our lesser used "sections" including the
"people" area so that our most used repos are more prominent.
Q: How does the "about" page work.
A: Just add a file like README, README.txt, README.md, README.rst and it
will automagically work. We can collapse or expand any sections we want,
I just took an initial stab at what seemed obvious to me.
Q: This looks a little different than normal cgit?
A: Yes, I've got to UI patches that have been reviewed, but not yet merged:
https://lists.zx2c4.com/pipermail/cgit/2016-September/003300.html
Q: What about android-git.linaro.org?
A: It will be converted after we finish with git.l.o
Q: What about our private git server?
A: There is a small privacy issue I'm trying to work out with the
maintainers so it can be used by us:
https://lists.zx2c4.com/pipermail/cgit/2016-September/003307.html
1: https://git.zx2c4.com/cgit/about/
The first test rebuild of Zesty Zapus was started on December 02 for all
architectures, all components (main component and seeded packages finished,
unseeded packages still building).
For arm64 and armhf the gcc-6 packages are based on the Linaro 6-2016.10
snapshot.
Results (please also look at the superseded builds) can be found at
http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20161202-zesty.html
Additional build failures for packages in zesty-proposed (not yet in zesty)
can be found at http://qa.ubuntuwire.com/ftbfs/
Please help fixing the build failures.
Another test rebuild using a snapshot of GCC 7 (not yet released) as the default
can be found at
http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20161202-gcc7-zesty.ht…
GCC 7 is not yet released and will not be used as the default compiler for the
17.04 release. GCC 7 packages can be found in the ubuntu-toolchain-r/test PPA.
Matthias