Skip to content

test(lmbench): 引入 lmbench 测试框架集成和自动测试脚本 - #1433

Open
mistcoversmyeyes wants to merge 39 commits into
DragonOS-Community:masterfrom
mistcoversmyeyes:feat/lmbench
Open

test(lmbench): 引入 lmbench 测试框架集成和自动测试脚本#1433
mistcoversmyeyes wants to merge 39 commits into
DragonOS-Community:masterfrom
mistcoversmyeyes:feat/lmbench

Conversation

@mistcoversmyeyes

Copy link
Copy Markdown
Contributor

No description provided.

mistcoversmyeyes and others added 11 commits August 12, 2026 22:18
- 从 DragonOS 镜像站安装 lmbench 二进制包
- 添加 lmbench 测试用例脚本,涵盖内存、进程、文件系统和网络等方面的性能测试
- 修改使用 ext2 文件系统的测试脚本为使用 ext4 文件系统
- 添加测试环境初始化脚本 init.sh ,清理脚本 clean_up.sh和环境变量配置脚本 env.sh
- 修复 `lmbench/mem_map_lat` 测例的权限问题,确保测试能够正确执行。
- 在 `ramfs_copy_files_bw` 测试中添加 `sudo`,以确保有足够的权限进行文件操作。
- 修复 `vfs_xx_lat` 系列测试缺少临时文件的问题,确保测试环境完整。
…NER hang

lmbench's BENCH_INNER macro (bench.h) loops `while(__result < 0.95 *
get_enough(0))`. Under virtualized timing compute_enough() can return
SHORT=1000000, making __iterations explode (<<=3 past the 1<<27 break
that resets __result=0) into an infinite while — the observed benchmp
hangs on WSL2 (lat_fifo/bw_unix/lat_sem/bw_tcp/lat_select tcp/lat_udp/
lat_unix_connect all busy-loop state=R until timeout).

Fix: precompute ENOUGH once via lmbench's `enough` tool (the standard
config-run flow: `ENOUGH=`../bin/$OS/enough``), then clamp to <=100000
so BENCH_INNER's inner calibration converges, with 50000 (REAL_SHORT)
fallback on hang/failure. Enough<=100000 makes the while(__result <
0.95*enough) target small enough to converge under timing jitter.

Root cause confirmed via systematic-debugging on host: ENOUGH<=100000
unblocks all hung tools (lat_pipe/lat_unix/lat_sem/bw_unix output normal),
ENOUGH=1000000 hangs, TIMING_O=0 LOOP_O=0 unblocks (skips BENCH_INNER).
Not a DragonOS kernel issue; guest 8/8 e2e implies guest timing is stable.
…te serial EINVAL

- unblock lmbench in app-blocklist so make installs the suite
- remove sudo / unsupported -W -N args from copy/mmap/ramfs test cases
- ramfs lat_fs: use default iterations + explicit tmp dir (was 360s timeout)
- init.sh: shrink fixtures 512M->64M, tolerate dd stderr EINVAL on serial close
- env.sh: enable LMBENCH_CREATE_TEST_FILES

Guest e2e verified: ramfs/copy metrics now ok (31 ok / 47 metrics).
… fixtures

- init.sh: always recreate 64MB fixtures; stale undersized files broke the
  size checks in bw_mmap_rd/bw_file_rd/lat_mmap/lat_pagefault
- mem_mmap_bw: 16m (<=64MB fixture); mem_pagefault_lat: dedicated 8MB file;
  vfs_read_pagecache_bw: 512m -> 64m (bw_file_rd validates size <= file)
- tcp_loopback_bw_*.meta: SEARCH_PATTERN now matches real bw_tcp output
  ("<size> <MB/s> MB/sec") instead of the guessed "socket connection"
- tcp_loopback_http_bw: build a web root, DOCROOT + port 8080, abs file_list
- tcp_virtio_*: proper server/client + -S shutdown lifecycle (was leaking
  daemons that held the fixed ports -> EADDRINUSE)
- unix_connect_lat/semaphore_lat: 10s bound; guest kernel can hang on the
  missing unix-socket bind / sem_open instead of failing fast

Guest e2e verified: 32 metrics, 23 ok (mem/pagecache/process fixes confirmed).
Comment thread .worktrees/feat-lmbench
lmbench server mode (-s) double-forks: $! captures the launcher PID
(already exited), not the daemon. When set -e aborts the script on
client failure, the explicit -S shutdown in the body never runs, and
the cleanup trap kill $SERVER_PID misses the daemon. Leaked daemons
persist on fixed ports (31234/31236/31237), corrupting subsequent
network tests that share the port.

Add the -S shutdown command to cleanup() in all 11 network test scripts
so the daemon is stopped on every exit path (set -e failure, timeout
SIGTERM, normal exit).

Signed-off-by: sparkzky <sparkhhhhhhhhhh@outlook.com>
@sparkzky

Copy link
Copy Markdown
Member

几个 commit 里提到的数字不太一样(8/8、31/47、32/23),想确认下以最新代码为准,现在是多少 ok / 总共多少个?有没有逐个测例的通过清单?
以及对于 failed 的那些,大概哪些是 DragonOS 内核还没实现的特性导致的,哪些是测例脚本本身的问题?

@mistcoversmyeyes mistcoversmyeyes left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's this

Something to be clean

@mistcoversmyeyes mistcoversmyeyes left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

几个 commit 里提到的数字不太一样(8/8、31/47、32/23),想确认下以最新代码为准,现在是多少 ok / 总共多少个?
由于 Full Run 的时候,中间部分测试用例会随机卡住,阻塞后续用例运行,故而每次 Full Run OK 的测试用例数目都不一样,但是大概是 31/47 这样。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

test Unitest/User space test

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants