Contents: general system sanity filesystem xfstests block layer performance measurement Bus testing CAN bus testing year 2038 test kernel tests kselftest kernelci all 0day tests

This page is a dumping ground for ideas for new tests that could be added to Fuego.

Try to keep the tests in categories as shown below.

general system sanity [edit section]

Here are some tests that are good for general system sanity:

• LTP system call test (already in Fuego)
• LTP posix test suite (already in Fuego)
• LSB-FHS - Linux Standard Base Filesystem Hierarchy Standard test
  • See https://www.opengroup.org/testing/lsb-fhs/

filesystem [edit section]

xfstests [edit section]

xfstests seems to be the new standard for measuring Linux file system performance. We should include this test in fuego.

See the following for more information:

• https://git.kernel.org/cgit/fs/xfs/xfstests-dev.git/
  • clone with 'git clone git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git'
  • I think this is the main upstream repository for xfstests (the repository at http://oss.sgi.com/ has been deprecated)
• An automated xfstests infrastructure using kvm
  • Ted Ts'o's work on automating xfstests
• Toward better testing
  • Dave Chimmer's report on the status of xfstests at an event in 2014

block layer performance measurement [edit section]

Possibly something simple like 'time dd ...' is useful for catching some things (and it's short).

Here is a post from Linus Walleij about using a simple dd to measure block layer performance. He found a regression of performance using the MQ block layer scheduler, using this.

I got blk-mq running for MMC/SD today and I see a gross performance
regression, from 37 MB/s to 27 MB/s on Ux500 7.38 GB eMMC
with a simple dd test:

BEFORE switching to MQ:

time dd if=/dev/mmcblk3 of=/dev/null bs=1M count=1024
1073741824 bytes (1.0GB) copied, 27.530335 seconds, 37.2MB/s
real    0m 27.54s
user    0m 0.02s
sys     0m 7.56s

AFTER switching to MQ:

time dd if=/dev/mmcblk3 of=/dev/null bs=1M count=1024
1073741824 bytes (1.0GB) copied, 37.170990 seconds, 27.5MB/s
real    0m 37.18s
user    0m 0.02s
sys     0m 7.32s

I will however post my hacky patch as a RFD to the blockdevs and
the block maintainers, along with the numbers and a speculation
about what may be causing it. asynchronous requests (request
pipelining) is one thing, another thing is front/back merge in
the block layer I guess.

Bus testing [edit section]

CAN bus testing [edit section]

From agl-discussions list Dec 13: https://lists.linuxfoundation.org/pipermail/automotive-discussions/2016-December/003056.html

I'm interested your benchmark amb can data. http://docs.automotivelinux.org/docs/apis_services/en/dev/reference/iotbzh2016/signaling/AGL-AppFW-CAN-Signaling-Benchmark.pdf

I want to test amb d-bus can data benchmark, So can you share your used "can data" and "amd configuration" ?

This test apparently has a CAN packet injector, written by Cogent.

year 2038 test [edit section]

Arnd Bergmann is a leading kernel expert on this topic. He gave a talk at Linaro Connect 2017 in Budapest. See his session at: http://connect.linaro.org/resource/bud17/bud17-512/ and an lwn.net report on it here: https://lwn.net/Articles/717076/

There's a page with some very small test snippets at: http://maul.deepsky.com/~merovech/2038.html

kernel tests [edit section]

kselftest [edit section]

kernelci [edit section]

• build test
• boot test

all 0day tests [edit section]

Figure out a way to run all existing 0day tests.