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>
If io_submit() returns -EAGAIN, that just means the io context is full
and we need to wait for completions - no need to die.
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
A recent libbcachefs update accidentally committed a change that dropped
the O_DIRECT flag - we definitely didn't want to do that.
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>
printk_ratelimited was behind an #ifdef CONFIG_PRINTK, which we don't
define, so it was a complete noop - oops.
Signed-off-by: Kent Overstreet <kent.overstreet@gmail.com>
We're reading device metadat in mostly sequential order - buffered IO
will be faster than O_DIRECT.
Signed-off-by: Kent Overstreet <kent.overstreet@gmail.com>
When deleting an entry from a heap that was at entry h->used - 1, we'd
end up calling heap_sift() on an entry outside the heap - the entry we
just removed - which would end up re-adding it to the heap and deleting
something we didn't want to delete. Oops...
Signed-off-by: Kent Overstreet <kent.overstreet@gmail.com>
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>
