technology.html

---
layout: default
title: "Technology - Split-Kernel Architecture"
description: "The Multikernel system offloads device drivers and interrupt processing to a dedicated kernel, enabling stronger isolation, native performance, and independent kernel lifecycle management."
permalink: /technology.html
---

<main>
    <!-- Hero Section -->
    <section class="hero">
        <div class="hero-container">
            <div class="hero-badge">
                <i data-lucide="cpu"></i>
                <span>Technology Overview</span>
            </div>

            <h1>Split-Kernel Architecture</h1>
            <p class="subtitle">The Multikernel system offloads all device drivers and interrupt processing to a dedicated device-kernel. Applications run in isolated app-kernels with dedicated resources and native hardware performance.</p>

            <div class="button-group">
                <a href="/getting-started.html" class="btn btn-primary">
                    <i data-lucide="rocket"></i>
                    Get Started
                </a>
                <a href="https://github.com/multikernel" target="_blank" rel="noopener noreferrer" class="btn btn-secondary">
                    <i data-lucide="github"></i>
                    View Source
                </a>
            </div>
        </div>
    </section>

    <!-- Why -->
    <section id="concept" class="value-section">
        <div class="section-container">
            <div class="value-content">
                <div class="value-text">
                    <div class="section-badge">
                        <i data-lucide="layers"></i>
                        <span>Background</span>
                    </div>
                    <h2 class="section-title">Why Split-Kernel</h2>
                    <p class="section-subtitle">A traditional Linux kernel runs application code, device drivers, and interrupt handlers on the same cores. Under load, interrupt processing steals CPU cycles from applications. Kernel workarounds like isolcpus, irqaffinity, NAPI threaded mode, and RPS/RFS reduce the problem but cannot eliminate it. Within a single kernel, bottom-half work can always reach application cores.</p>
                    <p class="section-subtitle">The split-kernel architecture removes this contention at the design level. Device processing is offloaded to a dedicated kernel on dedicated cores. Applications run in their own kernels where interrupts are structurally absent. Because Multikernel runs directly on hardware with no hypervisor, it works inside any standard cloud VM, providing kernel-level isolation without the performance penalty of nested virtualization.</p>
                </div>

                <div class="value-visual">
                    <div class="architecture-preview">
                        <div class="preview-title">Traditional: One Kernel</div>
                        <div class="architecture-layers">
                            <div class="layer multikernel-layer">
                                <div class="layer-label">App (userspace)</div>
                                <div class="layer-features">
                                    <span>syscall / VFS</span>
                                </div>
                            </div>
                            <div class="layer hardware-layer">
                                <div class="layer-label">Bottom Half (steals app CPU)</div>
                                <div class="layer-features">
                                    <span>TCP softirq</span>
                                    <span>NIC hardirq</span>
                                    <span>NVMe hardirq</span>
                                </div>
                            </div>
                        </div>
                        <div class="preview-benefit">All contexts compete for the same cores</div>
                    </div>
                </div>
            </div>
        </div>
    </section>

    <!-- Key Components -->
    <section id="solution" class="value-section">
        <div class="section-container">
            <div class="section-header">
                <div class="section-badge">
                    <i data-lucide="cpu"></i>
                    <span>Key Components</span>
                </div>
                <h2 class="section-title">The Multikernel System</h2>
                <p class="section-subtitle">Three components working together: isolated app-kernels for applications, a shared device-kernel for all I/O, and a lock-free shared memory layer connecting them.</p>
            </div>

            <div class="technologies-grid">
                <div class="technology-card primary">
                    <div class="tech-icon">
                        <i data-lucide="monitor"></i>
                    </div>
                    <h3 class="tech-title">App-Kernels</h3>
                    <p class="tech-description">Each application runs in its own Linux kernel on dedicated cores. These kernels contain no device drivers, no interrupt handlers, and no network stack. Practically all compute and memory resources go directly to the application.</p>
                </div>

                <div class="technology-card primary">
                    <div class="tech-icon">
                        <i data-lucide="hard-drive"></i>
                    </div>
                    <h3 class="tech-title">Device-Kernel</h3>
                    <p class="tech-description">All device drivers, interrupt handlers, TCP/IP stack, and I/O processing run in a dedicated device-kernel on its own cores. This kernel serves every app-kernel and has its own independent update and failure domain.</p>
                </div>

                <div class="technology-card primary">
                    <div class="tech-icon">
                        <i data-lucide="database"></i>
                    </div>
                    <h3 class="tech-title">DAXFS Shared Memory</h3>
                    <p class="tech-description">App-kernels and the device-kernel communicate through DAXFS, a filesystem built on shared DRAM with lock-free CAS-based coordination. Zero-copy, no serialization, no network round trips.</p>
                </div>
            </div>
        </div>
    </section>

    <!-- How It Works -->
    <section id="how-it-works" class="how-it-works">
        <div class="section-container">
            <div class="section-header">
                <div class="section-badge">
                    <i data-lucide="cog"></i>
                    <span>Under the Hood</span>
                </div>
                <h2 class="section-title">How It Works</h2>
                <p class="section-subtitle">Built entirely on existing Linux infrastructure. No new OS, no custom hypervisor, no compatibility gaps.</p>
            </div>

            <div class="technologies-grid">
                <div class="technology-card">
                    <div class="tech-icon">
                        <i data-lucide="play-circle"></i>
                    </div>
                    <h3 class="tech-title">Kernel Spawning via Kexec</h3>
                    <p class="tech-description">New kernel instances launch using Linux's kexec mechanism, extended to boot alongside the running kernel rather than replacing it. Each spawned kernel starts on its assigned CPUs and memory, fully independent.</p>
                </div>

                <div class="technology-card">
                    <div class="tech-icon">
                        <i data-lucide="sliders"></i>
                    </div>
                    <h3 class="tech-title">Resource Partitioning</h3>
                    <p class="tech-description">CPUs, memory, and device queues are assigned to each kernel using standard Linux hotplug interfaces. Resources can be rebalanced between kernels at runtime without rebooting.</p>
                </div>

                <div class="technology-card">
                    <div class="tech-icon">
                        <i data-lucide="hard-drive"></i>
                    </div>
                    <h3 class="tech-title">Hardware Queue Isolation</h3>
                    <p class="tech-description">Modern NICs and NVMe devices expose multiple hardware queues. The device-kernel gets exclusive access to device queues. No software bridge, no SR-IOV. True hardware-level I/O isolation.</p>
                </div>

                <div class="technology-card">
                    <div class="tech-icon">
                        <i data-lucide="box"></i>
                    </div>
                    <h3 class="tech-title">Docker Integration</h3>
                    <p class="tech-description">Spawned kernels boot directly into Docker images using DAXFS to share the container rootfs. No full OS init per instance. Applications run unmodified with standard Linux interfaces.</p>
                </div>
            </div>
        </div>
    </section>

    <!-- Comparison -->
    <section id="comparison" class="value-section">
        <div class="section-container">
            <div class="section-header">
                <h2 class="section-title">Split-Kernel vs. Existing Approaches</h2>
                <p class="section-subtitle">The split-kernel architecture combines the isolation of separate kernels with native hardware performance, without the overhead of virtualization or the limitations of kernel tuning.</p>
            </div>

            <div class="diagram-container">
                <img src="assets/images/comparison-architecture-diagrams.svg" alt="Comparison of VM, Container, and Multikernel architectures" class="architecture-diagram">
            </div>

            <div class="comparison-table">
                <table>
                    <thead>
                        <tr>
                            <th>Capability</th>
                            <th>Containers</th>
                            <th>VMs</th>
                            <th>Multikernel</th>
                        </tr>
                    </thead>
                    <tbody>
                        <tr>
                            <td>Isolation</td>
                            <td>Shared kernel</td>
                            <td>Full (hypervisor)</td>
                            <td>Separate kernels</td>
                        </tr>
                        <tr>
                            <td>Performance overhead</td>
                            <td>Minimal</td>
                            <td>5-20%</td>
                            <td>None</td>
                        </tr>
                        <tr>
                            <td>Kernel customization</td>
                            <td>No</td>
                            <td>Yes</td>
                            <td>Yes, per workload</td>
                        </tr>
                        <tr>
                            <td>Dynamic resource allocation</td>
                            <td>Yes</td>
                            <td>Limited</td>
                            <td>Yes (CPU/memory hotplug)</td>
                        </tr>
                        <tr>
                            <td>Zero-downtime kernel updates</td>
                            <td>No</td>
                            <td>With orchestration</td>
                            <td>Yes</td>
                        </tr>
                        <tr>
                            <td>Attack surface per workload</td>
                            <td>Full kernel</td>
                            <td>Reduced</td>
                            <td>Minimal (stripped kernel)</td>
                        </tr>
                        <tr>
                            <td>Noisy neighbor effect</td>
                            <td>Yes</td>
                            <td>Reduced</td>
                            <td>Eliminated</td>
                        </tr>
                        <tr>
                            <td>Works inside cloud VMs</td>
                            <td>Yes</td>
                            <td>Requires nested virt</td>
                            <td>Yes</td>
                        </tr>
                    </tbody>
                </table>
            </div>
        </div>
    </section>

    <!-- Use Cases -->
    <section id="use-cases" class="how-it-works">
        <div class="section-container">
            <div class="section-header">
                <div class="section-badge">
                    <i data-lucide="target"></i>
                    <span>Applications</span>
                </div>
                <h2 class="section-title">Use Cases</h2>
                <p class="section-subtitle">The split-kernel architecture enables workloads that require strong isolation, predictable performance, or independent kernel lifecycle management.</p>
            </div>

            <div class="features-grid">
                <div class="feature-card">
                    <div class="feature-icon">
                        <i data-lucide="bar-chart"></i>
                    </div>
                    <h3 class="feature-title">Latency-Sensitive Workloads</h3>
                    <p class="feature-description">Trading systems, real-time analytics, and game servers where interrupt jitter affects outcomes. App-kernel cores see zero interrupts by design.</p>
                </div>

                <div class="feature-card">
                    <div class="feature-icon">
                        <i data-lucide="brain"></i>
                    </div>
                    <h3 class="feature-title">AI Agent Sandboxing</h3>
                    <p class="feature-description">Each AI agent runs in its own app-kernel with full GPU access and kernel-level isolation. No virtualization layer between the agent and hardware.</p>
                </div>

                <div class="feature-card">
                    <div class="feature-icon">
                        <i data-lucide="refresh-cw"></i>
                    </div>
                    <h3 class="feature-title">Zero-Downtime Updates</h3>
                    <p class="feature-description">Replace the device-kernel while applications continue running. Roll back a bad driver update without restarting a single workload.</p>
                </div>

                <div class="feature-card">
                    <div class="feature-icon">
                        <i data-lucide="activity"></i>
                    </div>
                    <h3 class="feature-title">Fault Tolerance</h3>
                    <p class="feature-description">A driver crash in the device-kernel does not affect application kernels. The device-kernel recovers independently while applications continue running.</p>
                </div>

                <div class="feature-card">
                    <div class="feature-icon">
                        <i data-lucide="server"></i>
                    </div>
                    <h3 class="feature-title">Mixed Workload Isolation</h3>
                    <p class="feature-description">Run databases, web servers, and ML training on the same machine. Each workload gets its own kernel with dedicated resources and no noisy neighbors.</p>
                </div>

                <div class="feature-card">
                    <div class="feature-icon">
                        <i data-lucide="database"></i>
                    </div>
                    <h3 class="feature-title">CXL Memory Sharing</h3>
                    <p class="feature-description">Share data across kernel instances or CXL-connected hosts through DAXFS with lock-free concurrent access and a shared page cache.</p>
                </div>
            </div>
        </div>
    </section>
</main>