New test ideas
Try to keep the tests in categories as shown below.
- LTP system call test (already in Fuego)
- LTP posix test suite (already in Fuego)
- LSB-FHS - Linux Standard Base Filesystem Hierarchy Standard test
- interrupts are working (at correct or expected rate)
- modules that were expected are loaded correctly
- file systems were mounted with correct permissions and attributes
- busybox or toybox has all needed sub-commands
- shell has needed features (should be part of posix test, but I suspect it's not)
- kselftest - for kernel features
- libraries that were expected are present
- check out OpenVAS - a tool that checks for CVEs (from OSSJ)
See the following for more information:
- 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
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.
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.
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
- build test
- boot test