summaryrefslogtreecommitdiff
path: root/gemfeed
diff options
context:
space:
mode:
authorPaul Buetow <paul@buetow.org>2026-04-30 14:07:56 +0300
committerPaul Buetow <paul@buetow.org>2026-04-30 14:07:56 +0300
commitaeed324a599066b27e669b8bbb373fc592c3997e (patch)
treebf94d37758f8d7da26835fe53972371086896b58 /gemfeed
parentaa97bf21c131e06a601123901baf48285e62424c (diff)
Update content for html
Diffstat (limited to 'gemfeed')
-rw-r--r--gemfeed/DRAFT-unveiling-ior-ng.html4
1 files changed, 4 insertions, 0 deletions
diff --git a/gemfeed/DRAFT-unveiling-ior-ng.html b/gemfeed/DRAFT-unveiling-ior-ng.html
index 677594c0..634bdaf8 100644
--- a/gemfeed/DRAFT-unveiling-ior-ng.html
+++ b/gemfeed/DRAFT-unveiling-ior-ng.html
@@ -155,6 +155,10 @@ http://www.gnu.org/software/src-highlite -->
<br />
<span>A flamegraph is a histogram of stacks. Each horizontal bar is one entry in a stack; every bar directly above it is a child of that entry, and the stack you read top-to-bottom is the same shape as a call chain. In ior, "stack" doesn&#39;t mean function-call stack (we don&#39;t have userspace symbols). It means a tuple of dimensions of the trace: by default <span class='inlinecode'>comm/path/tracepoint</span>, so the bottom row is per-process names, the middle row is per-file paths, and the top row is the syscall (<span class='inlinecode'>enter_read</span>, <span class='inlinecode'>enter_openat</span>, etc.). A wide bar means lots of events landed in that bucket, a narrow bar means few. There is no time axis — left-to-right is just sort order, not chronology. The whole chart is one "where is the I/O coming from?" picture.</span><br />
<br />
+<span>One thing worth flagging because it&#39;s the unusual bit: this flamegraph is live. Most of the flamegraph tooling out there — Brendan Gregg&#39;s <span class='inlinecode'>flamegraph.pl</span>, all the <span class='inlinecode'>perf script | stackcollapse-* | flamegraph.pl</span> pipelines, every <span class='inlinecode'>pprof -web</span> invocation — produces a static SVG: capture a profile for N seconds, render once, browse the result. ior&#39;s tab is not that. Bars grow, shrink, appear, and disappear in real time as events stream in from the kernel — at full screen-refresh rate while the workload runs, with no pause. You can sit on this tab while you change something on the system (start a build, cycle a service, run a query) and watch the I/O shape mutate underneath you. That&#39;s a different mental model from the static "I have a profile, let me look at it" workflow most people are used to, and it&#39;s what makes the tab actually useful as an at-a-glance diagnostic surface rather than a post-mortem artifact.</span><br />
+<br />
+<span>Because it&#39;s live, there&#39;s also a way to throw away the accumulated history and start the rolling count from "now": <span class='inlinecode'>r</span> resets the baseline. Everything the flamegraph has been counting since launch (or since the last reset) is dropped, and from that moment the chart reflects only events that arrived after the reset. Useful for the "compare before vs after" workflow — change one thing on the box, hit <span class='inlinecode'>r</span> immediately, and the next thirty seconds of accumulation is a fresh picture of the new state.</span><br />
+<br />
<span>That visualisation buys you two things you can&#39;t easily get from a tabular view. First, hierarchy: it&#39;s immediately obvious whether one process is responsible for ten thousand reads on a single file, or ten thousand reads spread across a hundred files — the first looks like one tall pillar, the second looks like a wide ridge. Second, scale: bar width is proportional to the metric (count or bytes), so a process that did 95% of the work towers over the others. The eye picks that up instantly; the same fact in a sorted table requires reading numbers and doing the ratio mentally.</span><br />
<br />
<span>Useful workflows you can do entirely from this tab:</span><br />