LAT_CTX(8)

💖 LAT_CTX(8) — context switching benchmark 💖

okay bestie, this is a page from the LMBENCH manual, section 8, and it's all about lat_ctx, the context switching benchmark. sit down, hydrate, we're measuring switches 🦋

---

✨ NAME ✨

lat_ctx — context switching benchmark

---

🎀 SYNOPSIS 🎀

lat_ctx [ -P <parallelism> ] [ -W <warmups> ] [ -N <repetitions> ] [ -s
<size_in_kbytes> ] #procs [ #procs ...  ]

so those flags — -P <parallelism>, -W <warmups>, -N <repetitions>, -s <size_in_kbytes> — are literally what the page gives us, and then it's just a whole list of #procs values, like [ #procs ... ]. the page does not spell out what each flag does beyond that, and I am NOT about to invent lore, so we're keeping it exactly as written. periodt 💅

---

🌸 DESCRIPTION 🌸

lat_ctx measures context switching time for any reasonable number of processes of any reasonable size. iconic behavior honestly.

the processes are connected in a ring of Unix pipes. each process reads a token from its pipe, possibly does some work, and then writes the token to the next process. it's giving relay race, but make it syscalls 🫶

processes may vary in number. smaller numbers of processes result in faster context switches. and heads up — more than 20 processes is not supported. that's the cap, bestie, don't push it 💀

processes may also vary in size. a size of zero is the baseline process that does nothing except pass the token on to the next process. a process size of greater than zero means that the process does some work before passing on the token. the work is simulated as the summing up of an array of the specified size. the summing is an unrolled loop of about a 2.7 thousand instructions.

the effect is that both the data and the instruction cache get polluted by some amount before the token is passed on:

• the data cache gets polluted by approximately the process ``size''
• the instruction cache gets polluted by a constant amount, approximately 2.7 thousand instructions

the pollution of the caches results in larger context switching times for the larger processes. and this may be confusing, because the benchmark takes pains to measure only the context switch time, not including the overhead of doing the work. the subtle point — and it IS subtle, lowkey genius — is that the overhead is measured using hot caches.

as the number and size of the processes increases, the caches are more and more polluted until the set of processes do not fit. the context switch times go up because a context switch is defined as the switch time plus the time it takes to restore all of the process state, including cache state. which means the switch includes the time for the cache misses on larger processes. so yeah, the "extra" time is technically the switch. no cap 🌈

---

⭐ OUTPUT ⭐

the output format is intended as input to xgraph or some similar program. it's multi line:

• the first line is a title that specifies the size and non-context switching overhead of the test
• each subsequent line is a pair of numbers that indicates the number of processes and the cost of a context switch

the overhead and the context switch times are in micro second units. the numbers below are for a SPARCstation 2.

"size=0 ovr=179
2 71
4 104
8 134
16 333
20 438

---

😭 BUGS 😭

the numbers produced by this benchmark are somewhat inaccurate — they vary by about 10 to 15% from run to run. a series of runs may be done and the lowest numbers reported. the lower the number the more accurate the results. so like, the smallest number is the realest one 🍓

the reasons for the inaccuracies are possibly interaction between the VM system and the processor caches. it is possible that sometimes the benchmark processes are laid out in memory such that there are fewer TLB/cache conflicts than other times. and, direct quote energy: this is pure speculation on our part. they said "we don't know, we're guessing" and honestly? respect 🙈

---

💜 ACKNOWLEDGEMENT 💜

funding for the development of this tool was provided by Sun Microsystems Computer Corporation. ty for the bag 💰✨

---

👑 SEE ALSO 👑

• lmbench(8)

---

🧚 AUTHOR 🧚

Carl Staelin and Larry McVoy

comments, suggestions, and bug reports are always welcome. they're literally asking you to dm them, bestie, that's main character energy 💖

---

this page is from LMBENCH, and it's (c)1994-2000 Carl Staelin and Larry McVoy (the footer got cut off mid-"Lar…" but you get the vibe), stamped with $Date$ because version control said "you'll fill it in later." anyway — that's the whole page, go forth and benchmark, slay 💅🌸