1lmbench3-alpha1
2	Added new benchmark line, which determines the cache line size
3
4	Added new benchmark tlb, which determines the effective TLB size.
5	Note that this may differ from the hardware TLB size due to OS
6	TLB entries and super-pages.
7
8	Added new benchmark par_mem, which determines the possible
9	speedup due to multiple memory reads progressing in parallel.
10	This number usually depends highly on the portion of the
11	memory hierarchy being probed, with higher caches generally
12	having greater parallelism.
13
14	Added new benchmark cache, which determines the number of caches,
15	their sizes, latency, and available parallelism.  It also
16	reports the latency and available parallelism for main memory.
17
18	Added new benchmark lat_ops, which attempts to determine the
19	latency of basic operations, such as add, multiply and divide,
20	for a variety of data types, such as int, int64, float and
21	double.
22
23	Added new benchmark par_ops, which attempts to determine the
24	available scaling of the various basic operations for various
25	data types.
26
27	Added new benchmark stream, which reports memory bandwidth
28	numbers using benchmark kernels from John McCalpin's STREAM
29	and STREAM version 2 benchmarks.
30
31	Added new benchmark lat_sem, which reports SysV semaphore latency.
32
33	Added getopt() command line parsing to most benchmarks.
34
35	Added a new benchmark timing harness, benchmp(), which makes
36	it relatively easy to design and build benchmarks which
37	measure system performance under a fixed load.  It takes
38	a few parameters:
39		- initialize: a function pointer.  If this is non-NULL
40		  the function is called in the child processes after
41		  the fork but before any benchmark-related work is
42		  done.  The function is passed a cookie from the
43		  benchmp() call.  This can be a pointer to a
44		  data structure which lets the function know what
45		  it needs to do.
46		- benchmark: a function pointer.  This function
47		  takes two parameters, an iteration count "iters",
48		  and a cookie.  The benchmarked activity must be
49		  run "iters" times (or some integer multiple of
50		  "iters".  This function must be idempotent; ie.,
51		  the benchmark harness must be able to call it
52		  as many times as necessary.
53		- cleanup: a function pointer.  If this is non-NULL
54		  the function is called after all benchmarking is
55		  completed to cleanup any resources that may have
56		  been allocated.
57		- enough: If this is non-zero then it is the minimum
58		  amount of time, in micro-seconds, that the benchmark
59		  must be run to provide reliable results.  In most
60		  cases this is left to zero to allow the harness to
61		  autoscale the timing intervals to the system clock's
62		  resolution/accuracy.
63		- parallel: this is the number of child processes
64		  running the benchmark that should be run in parallel.
65		  This is really the load factor.
66		- warmup: a time period in micro-seconds that each
67		  child process must run the benchmarked process
68		  before any timing intervals can begin.  This is
69		  to allow the system scheduler time to settle in
70		  a parallel/distributed system before we begin
71		  measurements.  (If so desired)
72		- repetitions: If non-zero this is the number of
73		  times we need to repeat each measurement.  The
74		  default is 11.
75		- cookie: An opaque value which can be used to
76		  pass information to the initialize(), benchmark(),
77		  and cleanup() routines.
78	This new harness is now used by: bw_file_rd, bw_mem, bw_mmap_rd,
79	bw_pipe, bw_tcp, bw_unix, lat_connect, lat_ctx, lat_fcntl,
80	lat_fifo, lat_mem_rd, lat_mmap, lat_ops, lat_pagefault, lat_pipe,
81	lat_proc, lat_rpc, lat_select, lat_sem, lat_sig, lat_syscall,
82	lat_tcp, lat_udp, lat_unix, lat_unix_connect, and stream.
83