4300: Polish slide by changing <pre> to <table>.

diff --git a/2019-kvm-forum/4300-block-status-impact.html b/2019-kvm-forum/4300-block-status-impact.html
index 948e973..7d8d764 100644 (file)
--- a/2019-kvm-forum/4300-block-status-impact.html
+++ b/2019-kvm-forum/4300-block-status-impact.html
@@ -5,23 +5,50 @@
 <h1>Block status: does it change the status quo?</h1>
 
 <p>
-  Filler text - need a graphic here showing multiple combinations:
-
-  <br>[WZ] = WRITE_ZEROES
-  <br>[BS] = BLOCK_STATUS
-
-<pre>
-                  O(1) server             O(n) server
-pre-patch         [WZ]                    [WZ...........]
-
-status sees zero  [BS]                    [BS]
-                  (no improvement)        (noticeably faster)
-
-status sees data  [BS][WZ]                [BS][WZ...........]
-                 (noticeably slower)     (marginally slower)
-
-status is slow    [BS............]        [BS............]
-                  (noticeably slower)     (noticeably slower)
-</pre>
-
+  Checking whether a block is already zero will eliminate the need to
+  write zeroes to that block, but at what cost?
+
+  <p>
+  <span style="background-color: green; color: white;">block status reports hole</span>
+  <span style="background-color: red; color: white;">block status reports data</span>
+  <span style="background-color: blue; color: white;">write zeroes</span>
+
+  <p>
+  <table style="width:100%">
+    <tr>
+      <th></th>
+      <th>O(1) server</th>
+      <th>O(n) server</th>
+    </tr>
+    <tr>
+      <td>no block status</td>
+      <td><span style="background-color: blue; padding-right:20px;">&nbsp;</span></td>
+      <td><span style="background-color: blue; padding-right:200px;">&nbsp;</span></td>
+    </tr>
+    <tr>
+      <td>block status sees zero</td>
+      <td><span style="background-color: green; padding-right:20px;">&nbsp;</span></td>
+      <td><span style="background-color: green; padding-right:20px;">&nbsp;</span></td>
+    </tr>
+    <tr>
+      <td>block status sees data</td>
+      <td><span style="background-color: red; padding-right:20px;">&nbsp;</span>
+        <span style="background-color: blue; padding-right:20px;">&nbsp;</span></td>
+      <td><span style="background-color: red; padding-right:20px;">&nbsp;</span>
+        <span style="background-color: blue; padding-right:200px;">&nbsp;</span></td>
+    </tr>
+    <tr>
+      <td>block status is slow</td>
+      <td><span style="background-color: red; padding-right:250px;">&nbsp;</span>
+        <span style="background-color: blue; padding-right:20px;">&nbsp;</span></td>
+      <td><span style="background-color: red; padding-right:250px;">&nbsp;</span>
+        <span style="background-color: blue; padding-right:200px;">&nbsp;</span></td>
+    </tr>
+  </table>
+
+  <p>
+    If checking once per block is bad, can we instead check once per
+    image?
+  <p>Or why even check - what if we ensure the image starts
+    with all zeroes?
 </p>

diff --git a/2019-kvm-forum/notes-04-fast-zero b/2019-kvm-forum/notes-04-fast-zero
index 19622d0..c818417 100644 (file)
--- a/2019-kvm-forum/notes-04-fast-zero
+++ b/2019-kvm-forum/notes-04-fast-zero
@@ -53,15 +53,14 @@ didn't really help, for a couple of reasons.  If writing zeroes is
 fast, checking the destination first is either a mere tradeoff in
 commands (BLOCK_STATUS replacing WRITE_ZEROES when the destination is
 already zero) or a pessimization (BLOCK_STATUS still has to be
-followed by WRITE_ZEROES).  And if writing zeroes is slow, we have a
-speedup holes when BLOCK_STATUS itself is fast on pre-existing
-destination holes, but we encountered situations such as tmpfs that
-has a linear rather than constant-time lseek(SEEK_HOLE)
-implementation, where we ended up with quadratic behavior all due to
-BLOCK_STATUS calls.  Thus, for now, qemu-img convert does not use
-BLOCK_STATUS, and as mentioned earlier, I used the noextents filter in
-my test case to ensure BLOCK_STATUS is not interfering with timing
-results.
+followed by WRITE_ZEROES).  Conversely, if writing zeroes is slow, the
+penalty of the extra check when the destination is not a hole could be
+in the noise, but whether or not we have a definite speedup for
+avoiding WRITE_ZEROES depends on whether BLOCK_STATUS itself is fast -
+yet we encountered situations such as tmpfs that has a linear rather
+than constant-time lseek(SEEK_HOLE) implementation, where we ended up
+with quadratic behavior all due to BLOCK_STATUS calls.  Thus, for now,
+qemu-img convert does not use BLOCK_STATUS.
 
 * Heading: Pre-zeroing: a tale of two servers
 - 4400- .term