NAnasretdinov·Mar 7, 2026
Potentially https://github.com/hakavlad/prelockd ?
In Modernizing swapping: virtual swap spaceshakavlad
prelockd
Python2020–2026
hakavlad / prelockd
prelockd
Lock executables and shared libraries in memory to improve system responsiveness under low-memory conditions
6Distinct people
7Mentions
0Explicit recommenders
136GitHub stars
What to know before exploring
What it is
Lock executables and shared libraries in memory to improve system responsiveness under low-memory conditions
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- hakavlad/memavaild · linked in 3 of the same discussions
- hakavlad/le9-patch · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year7 dated mentions
Observed mentions: 2020-11-17 12:20:21 UTC to 2026-03-07 14:51:10 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
7 sourcesAuthor pushes abstract idea about "page reclamation" in front of ideas of performance, reliability and controllable service degradation which people actually want; because author believes that it is the one and only solution to them; and then defends swap because it is good for it.
No, this is just plain wrong. There are very specific problems which happen when there is not enough memory.
1. File-backed page reads causing more disk reads, eventually ending with "programs being executed from disk" (shared libraries are also mmaped) which feels like system lockup. This does not need any "egalitarian reclamation" abstraction and swap, and swap does not solve it. But it can be solved simply by reserving some minimal amount of memory for buf/cache, with which system is still responsive.
2. Eventually failure to allocate more memory for some pr
Read the rest
ocess. Any solutions like "page reclamation" with pushing unused pages to some swap can only increase maximum amount of memory which can be used before it happens, from one finite value to bigger finite value. When there is no memory to free without losing data, some process must be killed. Swap does not solve this. The least bad solution would be to warn user in advance and let them choose processes to kill.
See also https://github.com/hakavlad/prelockd
This may or may not preserve your desktop and other important applications in an OOM situation. https://github.com/hakavlad/prelockd
I've heard some good results with it and the applications locked in memory is configurable.
In Linux ate my RAM (2009)I wonder how does this compare to the state of the art solutions from the author of Nohang:
https://github.com/hakavlad/prelockd
https://github.com/hakavlad/memavaild
https://github.com/hakavlad/le9-patch
in terms of % saved memory or % prevented hangs/OOM / lost base runtime performance
In Introduce DAMON-based Proactive ReclamationHow will systemd-oomd communicate to the user?
I was using https://github.com/hakavlad/nohang
And it sent notification signaling to save your work before the application X will be killed. (I always wanted a way to click somewhere on the notification to prevent nohand from killing it when unwanted)
Also nohang use PSI data does oomd does it too?
Finally the author of nohang is working on arguably superior solutions:
https://github.com/hakavlad/prelockd
https://github.com/hakavlad/memavaild
https://github.com/hakavlad/le9-patch
It's unfortunate that systemd has chosen to integrate an inferior solution
In Systemd 248 RC3: systemd-oomd is now considered fully supportedLook at the new tools:
https://github.com/hakavlad/prelockd
https://github.com/hakavlad/memavaild
It can greatly improve responsiveness. Demo:
https://youtu.be/QquulJ06dAo - playing supertux + 12 `tail /dev/zero` in background
https://youtu.be/DsXEWvq60Rw - `tail /dev/zero`, swap on HDD, memavaild, no freezes
In Run Python Applications Efficiently with malloc_trim