You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Phase 16 & 17: Production Hardening and Developer Experience
Implemented major stability and developer productivity improvements:
- Robust Signal Handling: Interposer now delegates unmanaged SIGSEGV to previous handlers.
- Deadlock Prevention: Emulator uses 'busy_count' pinning to prevent eviction of active blocks.
- OOM Safety: Graceful fallback to host memory if Fabric allocation fails.
- Cooperative Mode: Added fabric_register_weight API for explicit weight registration.
- Debug & Validation: Added TFMBS_DEBUG and TFMBS_VALIDATE environment variables with signal-safe verification.
- Developer Tools: Added tfmbs-run CLI wrapper and benchmark_performance script.
- Documentation: New guides for Production Hardening and DX, plus updated User Manual.
- Verified system correctness with updated C tests and pytest suite.
Co-authored-by: t81dev <207451414+t81dev@users.noreply.github.com>
Copy file name to clipboardExpand all lines: USER_MANUAL.md
+14-4Lines changed: 14 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -40,18 +40,28 @@ Welcome to the **Ternary Fabric** user manual. This documentation is designed to
40
40
The Ternary Fabric can accelerate applications like `llama.cpp` without source code modifications using the `libtfmbs_intercept.so` interposer.
41
41
42
42
### Usage
43
+
The easiest way to run an application with Fabric acceleration is using the `tfmbs-run` tool:
43
44
```bash
44
-
# Enable Fabric acceleration with CPU short-circuiting
45
-
export FABRIC_SHORT_CIRCUIT=1
46
-
LD_PRELOAD=./libtfmbs_intercept.so ./my_app
45
+
./tools/tfmbs-run ./my_app
47
46
```
48
47
49
48
### Environment Variables
50
49
*`FABRIC_SHORT_CIRCUIT=1`: Enables the interposer to bypass CPU compute loops once weights are resident in the Fabric.
51
-
*`TFMBS_DEBUG=1`: Enables verbose logging of memory allocations and offloading events.
50
+
*`TFMBS_DEBUG=1`: Enables detailed real-time logging of memory registry changes, GEMV offloads, and async waits.
51
+
*`TFMBS_VALIDATE=1`: Bit-exact comparison of Fabric results against a CPU reference for every operation.
52
+
53
+
### Cooperative Mode (Explicit Registration)
54
+
If you want to avoid the overhead of the "First Scan" heuristic, you can explicitly register weight buffers by calling `fabric_register_weight(ptr, size)` from your application.
52
55
53
56
---
54
57
58
+
## ⚠️ Best Practices & Limitations
59
+
60
+
### When NOT to use Fabric
61
+
-**Small Matrices:** GEMV operations smaller than 1024 elements may incur more overhead than they save.
62
+
-**High-Precision Requirements:** Fabric is optimized for ternary weights. High-precision (FP32/BF16) weights will be quantized/compressed, which may impact accuracy.
63
+
-**Frequent Writes:** If you frequently write to weight buffers, the interposer will constantly need to re-pack them into PT-5 format.
64
+
55
65
## 📊 Interpreting Telemetry
56
66
57
67
When running with the interposer or Python API, the Fabric provides real-time telemetry:
This phase focuses on making the TFMBS "Illusion" stable, reliable, and safe for production-like environments.
4
+
5
+
## 🛡️ Robust Signal Handling
6
+
7
+
The TFMBS interposer uses `SIGSEGV` to intercept memory accesses and redirect them to the Fabric. Previously, any unmanaged segfault would cause an immediate process exit.
8
+
9
+
-**Handler Delegation:** The interposer now saves the previous signal handler (`struct sigaction`) and delegates to it if a faulting address is not found in the TFMBS registry.
10
+
-**Proper Crashes:** Real segmentation faults in the host application now behave normally (causing a crash with a core dump) rather than being swallowed or causing a mysterious exit.
11
+
12
+
## 💾 Memory & Deadlock Safety
13
+
14
+
-**OOM Awareness:** The Fabric emulator (`emu_fabric_alloc`) now correctly handles out-of-memory situations where all blocks are "busy" (pinned by active asynchronous tasks).
15
+
-**Graceful Fallback:** If Fabric memory cannot be allocated, the interposer transparently falls back to host memory (via standard `malloc`).
16
+
-**Busy Pinning:** Tasks in the asynchronous pipeline pin their associated memory blocks, preventing the LRU evictor from removing data that is currently being used by a hardware kernel.
17
+
18
+
## 🤝 Cooperative Mode (Explicit API)
19
+
20
+
While the transparent interposer is the primary interface, some applications may prefer explicit control to reduce overhead or improve reliability.
21
+
22
+
-**`fabric_register_weight(ptr, size)`**: Explicitly marks a host memory buffer as a weight buffer for the Fabric. This bypasses the heuristic "First Scan" phase and immediately establishes residency.
23
+
24
+
## 🛠️ Error Propagation
25
+
26
+
-**Status Codes:**`fabric_wait` and other internal APIs have been updated to return integer status codes instead of `void`. This allows the interposer to detect kernel failures and potentially fall back to CPU compute if a hardware error occurs.
Phase 17 improves the tools and visibility available to developers working with TFMBS.
4
+
5
+
## 🔍 Debugging & Visualization
6
+
7
+
-**`TFMBS_DEBUG=1`**: Setting this environment variable enables detailed real-time logging in the interposer. It logs:
8
+
- Memory registry additions.
9
+
- GEMV offload triggers and inferred dimensions.
10
+
- Asynchronous wait events and short-circuit jumps.
11
+
-**`TFMBS_VALIDATE=1`**: Enabling validation mode causes the interposer to run a bit-exact reference CPU implementation of every GEMV task immediately after it completes on the Fabric. It compares the results and logs any mismatches.
12
+
13
+
## 🚀 CLI Tools
14
+
15
+
-**`tfmbs-run`**: A wrapper script located in `tools/` that automatically configures `LD_PRELOAD` and `LD_LIBRARY_PATH`.
16
+
- Usage: `./tools/tfmbs-run ./my_app`
17
+
-**`benchmark_performance.sh`**: A tool to compare the wall-clock performance of the Fabric against a pure CPU baseline using the `mock_llama` benchmark.
18
+
19
+
## 📈 Performance Profiling
20
+
21
+
-**Wall-Clock Metrics:** We've shifted focus from "Peak GOPS" to "End-to-End Time", providing a more realistic view of the system's impact on inference latency.
0 commit comments