Fixed heading sizes

Author: madeline-underwood

content/learning-paths/servers-and-cloud-computing/bolt-merge/how-to-2.md

@@ -249,7 +249,7 @@ llvm-bolt $HOME/mysql-server/build/bin/mysqld \
   2>&1 | tee $HOME/mysql-server/bolt-instrumentation-readonly.log
 ```
 
-### Explanation of key options
+## Explanation of key options
 
 These flags control how BOLT collects runtime data from the instrumented binary. Understanding them helps ensure accurate and comprehensive profile generation:
 

content/learning-paths/servers-and-cloud-computing/bolt-merge/how-to-3.md

@@ -64,22 +64,22 @@ After running each benchmark, cleanly shut down the MySQL server and reset the i
 ```bash
 ./bin/mysqladmin -u root shutdown ; rm -rf /dev/shm/dataset ; cp -R data/ /dev/shm/dataset
 ```
-### Verify that both profiles exist
+## Verify that both profiles exist
 
 Verify that the following `.fdata` files have been generated:
 
 ```bash
 ls -lh $HOME/mysql-server/build/profile-readonly.fdata
 ls -lh $HOME/mysql-server/build/profile-writeonly.fdata
 ```
-### Merge the read and write profiles
+## Merge the read and write profiles
 
 Both `.fdata` files should now exist and contain valid data:
 
 - `profile-readonly.fdata`
 - `profile-writeonly.fdata`
 
-### Merge the feature profiles
+## Merge the feature profiles
 
 Use `merge-fdata` to combine the feature-specific profiles into one comprehensive `.fdata` file:
 
@@ -97,15 +97,15 @@ Profile from 2 files merged.
 
 This creates a single merged profile (`profile-merged.fdata`) covering both read-only and write-only workload behaviors.
 
-### Verify the merged profile
+## Verify the merged profile
 
 Confirm the merged profile file exists and is non-empty:
 
 ```bash
 ls -lh $HOME/mysql-server/build/profile-merged.fdata
 ```
 
-### Optimize the binary with the merged profile
+## Optimize the binary with the merged profile
 
 Use LLVM-BOLT to generate the final optimized binary using the merged `.fdata` file:
 

content/learning-paths/servers-and-cloud-computing/bolt-merge/how-to-4.md

@@ -10,9 +10,7 @@ layout: learningpathall
 
 In this section, you'll learn how to instrument and optimize shared libraries, and specifically, `libssl.so` and `libcrypto.so` using BOLT. These libraries are used by MySQL, and optimizing them can improve overall performance. You'll rebuild OpenSSL from source to include symbol information, then collect profiles and apply BOLT optimizations.
 
-## Instrument Shared Libraries 
-
-### Prepare instrumentable versions
+## Prepare instrumentable versions
 
 If system libraries like `/usr/lib/libssl.so` are stripped, rebuild OpenSSL from source with relocations:
 
@@ -25,7 +23,7 @@ make -j$(nproc)
 make install
 ```
 
-### Instrument libssl.so
+## Instrument libssl.so
 
 Use `llvm-bolt` to instrument `libssl.so.3`:
 
@@ -42,7 +40,7 @@ llvm-bolt $HOME/bolt-libs/openssl/lib/libssl.so.3 \
 
 Launch MySQL with the instrumented `libssl.so` and run a read+write Sysbench test to populate the profile
 
-### Optimize libssl using the profile
+## Optimize libssl using the profile
 
 After running the read+write test, ensure `libssl-readwrite.fdata` is populated.
 
@@ -62,7 +60,7 @@ llvm-bolt $HOME/bolt-libs/openssl/lib/libssl.so.3 \
   2>&1 | tee $HOME/mysql-server/build/bolt-libssl.log
 ```
 
-### Replace the library at runtime
+## Replace the library at runtime
 
 Copy the optimized version over the original and export the path:
 
@@ -88,7 +86,7 @@ libssl.so.3 => /home/ubuntu/bolt-libs/openssl/libssl.so.3
 
 This ensures MySQL will dynamically load the optimized `libssl.so`.
 
-### Run the final workload and validate performance
+## Run the final workload and validate performance
 
 Start the BOLT-optimized MySQL binary and link it against the optimized `libssl.so`. Run the combined workload:
 
@@ -119,11 +117,11 @@ taskset -c 7 ./src/sysbench \
 
 In the next step, you'll optimize an additional critical external library (`libcrypto.so`) using BOLT, following a similar process as `libssl.so`. Afterward, you'll interpret performance results to validate and compare optimizations across baseline and merged scenarios.
 
-### Optimize libcrypto.so with BOLT
+## Optimize libcrypto.so with BOLT
 
 Follow these steps to instrument and optimize `libcrypto.so`:
 
-### Instrument libcrypto.so
+## Instrument libcrypto.so
 
 ```bash
 llvm-bolt $HOME/bolt-libs/openssl/libcrypto.so.3 \
@@ -137,7 +135,7 @@ llvm-bolt $HOME/bolt-libs/openssl/libcrypto.so.3 \
 ```
 Launch MySQL using the instrumented shared library and run a read+write Sysbench test to populate the profile.
 
-### Optimize libcrypto using the profile
+## Optimize libcrypto using the profile
 After running the read+write test, ensure `libcrypto-readwrite.fdata` is populated.
 
 Run BOLT on the uninstrumented libcrypto.so using the collected read+write profile to generate an optimized library:

content/learning-paths/servers-and-cloud-computing/bolt-merge/how-to-5.md

@@ -12,7 +12,7 @@ This section compares the performance of baseline binaries with BOLT-optimized v
 
 All tests used Sysbench with the flags `--time=0 --events=10000`. This configuration ensures that each test completes exactly 10,000 requests per thread, delivering consistent workload runtimes  across runs.
 
-### Baseline performance (without BOLT)
+## Baseline performance (without BOLT)
 
 | Metric                     |Read-only  | Write-only  | Read + write  |
 |---------------------------|----------------------|------------------------|------------------------|
@@ -22,7 +22,7 @@ All tests used Sysbench with the flags `--time=0 --events=10000`. This configura
 | Latency 95th % (ms)       | 1.04                 | 0.83                   | 1.79                   |
 | Total time (s)            | 9.93                 | 4.73                   | 15.40                  |
 
-### Performance comparison: merged and non-merged instrumentation
+## Performance comparison: merged and non-merged instrumentation
 
 | Metric                     | Regular BOLT (read + write, system libssl) | Merged BOLT (read + write + libssl) |
 |---------------------------|---------------------------------------------|-------------------------------------------------|
@@ -42,7 +42,7 @@ Second test run:
 | Latency 95th % (ms)       | 1.39                                        | 1.37                                            |
 | Total time (s)            | 239.9                                       | 239.9                                           |
 
-### Performance across BOLT optimizations
+## Performance across BOLT optimizations
 
 | Metric                     | 	BOLT read-only | BOLT write-only | Merged BOLT (read + write + libssl) | Merged BOLT (read + write + libcrypto) | Merged BOLT (read + write + libcrypto + libssl) |
 |---------------------------|---------------------|-------------------|----------------------------------|------------------------------------|-------------------------------------------|
@@ -56,13 +56,13 @@ Second test run:
 All Sysbench and .fdata file paths, as well as taskset usage, should match the conventions in previous steps: use Sysbench from PATH (no src/), use /usr/share/sysbench/ for Lua scripts, and use $HOME-based paths for all .fdata and library files. On an 8-core system, use taskset -c 7 for Sysbench and avoid contention with mysqld.
 {{% /notice %}}
 
-### Key metrics to analyze
+## Key metrics to analyze
 
 - **TPS (transactions per second)** – higher is better  
 - **QPS (queries per second)** – higher is better  
 - **Latency (average and 95th percentile)** – lower is better
 
-### Conclusion
+## Conclusion
 
 - BOLT-optimized binaries clearly outperform baseline versions by improving instruction cache usage and shortening execution paths.
 - Merging feature-specific profiles does not negatively affect performance. Instead, they allow better tuning for varied real-world workloads by capturing a broader set of runtime behaviors.