We seem to be hitting a rare crash in the exit path of fsck - when
shutting down the shrinker thread. Disable exiting the shrinker thread
as a workaround.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Reading from /proc/meminfo is really slow
We don't want to start swapping to disk.
Deceptively, memory available goes up when we start to swap to disk making
performance even worse.
To mitigate this:
1. replace reading from meminfo with proper system calls.
2. attempt to lock allocations in physical memory space.
3. check our own allocated memory instead of available memory.
4. still check available memory in the off chance we're trying to play
nice with other apps.
Signed-off-by: Daniel Hill <daniel@gluo.nz>
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
- Spin up a background thread to call the shrinkers every 1 second
- Memory allocations will only call reclaim after a failed allocation,
not every single time
This will be a major performance boost on allocation intensive
workloads.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
This would correspond to GFP_RECLAIM in the kernel - but we don't
distinguish between different types of reclaim here.
This solves a deadlock in the btree node memory allocation path - we
allocate with the btree node cache lock held but without GFP_KERNEL set.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
After memory allocation failure, don't rely on /proc/meminfo to figure
out how much memory we should free - instead unconditionally free 1/8th
of each cache.
Signed-off-by: Kent Overstreet <kent.overstreet@gmail.com>
