Hackathons, Projects — July 2026
FORESIGHT
Top 6 national finalist at the Divergent National Cup 2026. I helped build a Linux memory manager that prepares RAM before idle applications return.
In two six-pair WSL2 studies, FORESIGHT cut memory-stall time by 78.98% in one workload and reduced a real image-processing job's median runtime by 25.03% in another.
FORESIGHT predicts when Linux workloads will need memory and prepares it before they return.
National finalist in the 2026 competition.
Measured against FORESIGHT-off in one six-pair constrained WSL2 study.
Every measured escrow in the two final studies returned its memory on time.
The problem
Linux can see memory pressure and identify pages that have gone cold. What it usually does not know is when a specific application will become active again. That matters on a memory-constrained machine. Keeping every inactive working set in normal RAM can leave active work waiting, but reclaiming too aggressively can make an application stumble when it wakes back up.
Our four-person team built FORESIGHT around a direct question: what if a memory manager learned an application’s return pattern and treated freed memory like a temporary loan with a deadline?
What I built
I worked across the optimizer, Linux backend, benchmarks, and presentation site. My main contributions were:
- correcting how the optimizer measured actions and reported whether the host could actually perform them;
- building deadline-carrying memory leases and the production multi-slice escrow policy;
- writing real-workload benchmark tooling and committing the raw evidence behind our claims;
- connecting the competition presentation to those measured results; and
- testing failure cases instead of treating every increase in available memory as a win.
The result was a released Linux prototype, not a general-purpose service deployed across thousands of machines. That distinction shaped how we tested it and how I describe it here.
How FORESIGHT works
FORESIGHT reads Linux memory pressure, page activity, swap use, and per-process signals. Its Reactivation-Hazard Model tracks how long stable process roles remain idle and how often they wake. When a process has a predictable rhythm and verified-cold anonymous pages, FORESIGHT can temporarily move exact memory ranges into compressed zram.
Those ranges form a temporal memory escrow. Each escrow has a conservative return deadline. FORESIGHT stops taking memory before the restoration window, checks which owned pages are still swapped, and faults those pages back in before the application is expected to return.
The presentation site showed how measured page activity becomes a conservative return estimate.
The system does not count a requested action as a success. It compares kernel counters before and after the action, tracks the exact ranges it owns, and records whether the later return met its deadline. A safety governor can reduce or stop action after harmful outcomes.
Architecture
Linux kernel signals
procfs, PSI, page activity, zram, and VmSwap
Linux backend
Measure, certify, demote, and prefault exact memory ranges
FORESIGHT core
RHM, planner, safety governor, and escrow lifecycle
Audit and interfaces
Outcome ledger, CLI, and React dashboard
Dashboard memory-layer graphic.
The core engine and planner are written in Rust. The Linux backend uses process_madvise with MADV_COLD and MADV_PAGEOUT on private, writable anonymous ranges. Restoration checks which owned pages remain swapped and prefaults them through sparse reads. A root daemon exposes status through a small JSON protocol, which is used by the CLI and dashboard.
Measured results
The strongest evidence came from two separate six-pair crossover studies on a constrained WSL2 environment. Each pair ran the same workload with FORESIGHT off and on.
CUDA-pressure workload
78.98% less PSI memory-stall time and 90.83% fewer return faults.
Boundary: foreground CUDA throughput was statistically unchanged.
878 MB image ETL
25.03% lower median wall time, 79.52% less PSI, and 77.65% fewer return faults.
Boundary: one of the six treated runs was 3.6% slower.
Both final studies
12 of 12 escrows completed with no deadline misses.
Boundary: this does not prove every workload benefits.
The studies measured 259.20 and 131.61 GiB-seconds of memory dividend. I keep the results separate because they came from different workloads. The useful result was not one large free-memory screenshot. It was capacity held for a measured amount of time and returned before a deadline.
Where it did not help
Some results changed how we designed the system. Forced optimization made short CPU PCA and SQLite tasks slower in single-pair screens. A GPU-bound control showed no meaningful CUDA speedup. The strongest tests ran under constrained WSL2, while exact page lifecycle behavior was separately checked in a virtualized Ubuntu environment.
FORESIGHT is also Linux-only. Its full engine needs privileges, zram, PSI and procfs access, and working cross-process process_madvise. It manages system RAM, not GPU memory. When the host cannot support an action, the correct behavior is to report that boundary instead of pretending an optimization happened.
Competition outcome
FORESIGHT finished as a Top 6 national finalist at the Divergent National Cup 2026. By the end of the project, we had a released Linux build, a dashboard, a presentation site, repeated workload studies, and committed evidence for the main performance claims.
The part I value most is the audit loop we built around the optimizer. Working on FORESIGHT made me think less about whether a system can take an action and more about whether it can prove the action helped, restore what it borrowed, and back off when the prediction was wrong.
Current status
FORESIGHT remains a completed hackathon prototype and research implementation. The code repository and old GitHub Pages deployment are not currently public, so I am not linking to an install command or live demo here.