LMBENCH(8)

✨ LMBENCH ✨

okay so bestie, this is lmbench(8) — the system benchmarks page 💅 and honestly? it's giving main character energy for anyone who wants to know what their computer is actually doing.

---

🌸 NAME 🌸

lmbench — system benchmarks. that's it, that's the vibe 🎀

---

💖 DESCRIPTION 💖

lmbench is a whole series of micro benchmarks, and their entire job is to measure basic operating system and hardware system metrics. no cap. the benchmarks fall into three general classes: bandwidth, latency, and ``other''. yes, "other" is literally in quotes in the original, it's iconic 🦋

most of the lmbench benchmarks use a standard timing harness described in timing(3), and they share a few standard options: parallelism, warmup, and repetitions. let's break it down:

• parallelism — the number of benchmark processes to run in parallel. this is primarily useful when you're measuring the performance of SMP or distributed computers, and you can use it to evaluate the system's performance scalability 👑
• warmup — the minimum number of microseconds the benchmark should execute the benchmarked capability before it begins measuring performance. again, this is primarily useful for SMP or distributed systems, and it's intended to give the process scheduler time to "settle" and migrate processes to other processors. by measuring performance over various warmup periods, users may evaulate the scheduler's responsiveness ✨
• repetitions — the number of measurements that the benchmark should take. this lets lmbench provide greater or lesser statistical strength to the results it reports. the default number of repetitions is 11 💫

---

🌈 BANDWIDTH MEASUREMENTS 🌈

data movement is fundamental to the performance on most computer systems. fr fr. the bandwidth measurements are intended to show how the system can move data. you can compare the results of the bandwidth metrics, but care must be taken to understand what it is that is being compared, bestie — don't just yolo the numbers 🫶

the bandwidth benchmarks can be reduced to two main components: operating system overhead and memory speeds. they report their results as megabytes moved per second, but please note that the data moved is not necessarily the same as the memory bandwidth used to move the data. consult the individual man pages for more info 💜

each bandwidth benchmark, with a brief overview of its intent:

• bw_file_rd — reading and summing of a file via the read(2) interface.
• bw_mem_cp — memory copy.
• bw_mem_rd — memory reading and summing.
• bw_mem_wr — memory writing.
• bw_mmap_rd — reading and summing of a file via the memory mapping mmap(2) interface.
• bw_pipe — reading of data via a pipe.
• bw_tcp — reading of data via a TCP/IP socket.
• bw_unix — reading data from a UNIX socket.

---

🦋 LATENCY MEASUREMENTS 🦋

control messages are also fundamental to the performance on most computer systems. the latency measurements are intended to show how fast a system can be told to do some operation. the results of the latency metrics can be compared to each other for the most part — in particular, the pipe, rpc, tcp, and udp transactions are all identical benchmarks carried out over different system abstractions 👀

latency numbers here should mostly be in microseconds per operation. remember that bestie, it matters 💅

• lat_connect — the time it takes to establish a TCP/IP connection.
• lat_ctx — context switching; the number and size of processes is varied.
• lat_fcntl — fcntl file locking.
• lat_fifo — ``hot potato'' transaction through a UNIX FIFO.
• lat_fs — creating and deleting small files.
• lat_pagefault — the time it takes to fault in a page from a file.
• lat_mem_rd — memory read latency (accurate to the ~2-5 nanosecond range, reported in nanoseconds).
• lat_mmap — time to set up a memory mapping.
• lat_ops — basic processor operations, such as integer XOR, ADD, SUB, MUL, DIV, and MOD, and float ADD, MUL, DIV, and double ADD, MUL, DIV.
• lat_pipe — ``hot potato'' transaction through a Unix pipe.
• lat_proc — process creation times (various sorts).
• lat_rpc — ``hot potato'' transaction through Sun RPC over UDP or TCP.
• lat_select — select latency
• lat_sig — signal installation and catch latencies. also protection fault signal latency.
• lat_syscall — non trivial entry into the system.
• lat_tcp — ``hot potato'' transaction through TCP.
• lat_udp — ``hot potato'' transaction through UDP.
• lat_unix — ``hot potato'' transaction through UNIX sockets.
• lat_unix_connect — the time it takes to establish a UNIX socket connection.

---

🎀 OTHER MEASUREMENTS 🎀

• mhz — processor cycle time
• tlb — TLB size and TLB miss latency
• line — cache line size (in bytes)
• cache — cache statistics, such as line size, cache sizes, memory parallelism.
• stream — John McCalpin's stream benchmark
• par_mem — memory subsystem parallelism. how many requests can the memory subsystem service in parallel, which may depend on the location of the data in the memory hierarchy.
• par_ops — basic processor operation parallelism.

---

👑 SEE ALSO 👑

bargraph(1), graph(1), lmbench(3), results(3), timing(3), bw_file_rd(8), bw_mem_cp(8), bw_mem_wr(8), bw_mmap_rd(8), bw_pipe(8), bw_tcp(8), bw_unix(8), lat_connect(8), lat_ctx(8), lat_fcntl(8), lat_fifo(8), lat_fs(8), lat_http(8), lat_mem_rd(8), lat_mmap(8), lat_ops(8), lat_pagefault(8), lat_pipe(8), lat_proc(8), lat_rpc(8), lat_select(8), lat_sig(8), lat_syscall(8), lat_tcp(8), lat_udp(8), lmdd(8), par_ops(8), par_mem(8), mhz(8), tlb(8), line(8), cache(8), stream(8)

---

💜 ACKNOWLEDGEMENT 💜

funding for the development of these tools was provided by Sun Microsystems Computer Corporation 🫶

a large number of people have contributed to the testing and development of lmbench. every single one of them, legends ✨

---

📜 COPYING 📜

the benchmarking code is distributed under the GPL with additional restrictions, see the COPYING file. read it bestie, it's important 💅

---

🌟 AUTHOR 🌟

Carl Staelin and Larry McVoy

comments, suggestions, and bug reports are always welcome. like actually, they want them, slide into their mentions 🙈

---

and that's the whole page, periodt 🎀 this LMBENCH(8) page came from the LMBENCH manual, and the fine print at the bottom reads (c)1994-2000 Larry McVoy and Carl... $Date$ — so yeah, copyright 1994-2000 by Larry McVoy and Carl, and there's a $Date$ placeholder where the date lives. iconic behavior, we love a version-control keyword 😭💖