Let's imagine you want to profile the I/O for the microSD card device on the Wandboard. By booting the system from the network, as seen in the Configuring network booting for a development setup recipe from Chapter 1, The Build System, you can avoid unnecessary access to the device by the system.
For this example, we will disable the journal from the ext4 partition by doing the following:
# e2fsck /dev/mmcblk2p1 # tune2fs -O ^has_journal /dev/mmcblk2p1
Check that /dev/mmcblk2p1 is the correct partition for your device by checking into the boot log messages with the dmesg command. You should see something like the following:
[ 0.000000] mmc2: SDHCI controller on 2198000.usdhc [2198000.usdhc] using ADMA
[ 0.000000] mmc2: host does not support reading read-only switch, assuming write-enable
[ 0.000000] mmc2: new high speed SDHC card at address 1234
[ 0.000000] mmcblk2: mmc2:1234 SA04G 3.68 GiB
[ 0.000000] mmcblk2: p1
[ 0.000000] mmc2: SDHCI controller on 2198000.usdhc [2198000.usdhc] using ADMA
[ 0.000000] mmc2: host does not support reading read-only switch, assuming write-enable
[ 0.000000] mmc2: new high speed SDHC card at address 1234
[ 0.000000] mmcblk2: mmc2:1234 SA04G 3.68 GiB
[ 0.000000] mmcblk2: p1
And then mount it with the following:
# mount /dev/mmcblk2p1 /mnt EXT4-fs (mmcblk2p1): mounted filesystem without journal. Opts: (null)
Other tweaks may be needed for effective profiling of a specific workload.
The workflow to profile a specific workload is as follows:
- Start blktrace to gather tracing data on the /dev/mmcblk2 device with the following:
# blktrace /dev/mmcblk2
- Start the workload to profile, for example, the creation of a 10 KB file. Open an SSH connection to the target and execute the following:
# dd if=/dev/urandom of=/mnt/home/root/random-10k-file bs=1k
count=10 conv=fsync 10+0 records in 10+0 records out 10240 bytes (10 kB, 10 KiB) copied, 2.1445 s, 4.8 kB/s
- Stop the profiling on the console with Ctrl + C. This will create a file in the same directory called mmcblk2.blktrace.0 . You will see the following output:
=== mmcblk2 === CPU 0: 32 events, 2 KiB data CPU 1: 1 events, 1 KiB data CPU 2: 22 events, 2 KiB data CPU 3: 0 events, 0 KiB data Total: 55 events (dropped 0), 3 KiB data
Some useful options for blktrace are:
- -w: This is used to run only for the specified number of seconds
- -a: This adds a mask to the current file, where the masks can be:
- barrier: This refers to the barrier attribute
- complete: This refers to an operation completed by the driver
- fs: These are the FS requests
- issue: This option refers to operations issued to the driver
- pc: This refers to packet command events
- queue: This option represents queue operations
- read: This refers to read traces
- requeue: This is used for requeue operations
- sync: This represents synchronous attributes
- write: This refers to write traces