kernel/linux.git/fs/bcachefs/btree_cache.c, branch v6.12.80

bcachefs: btree_cache.freeable list fixes

2024-11-07T21:48:21+00:00

When allocating new btree nodes, we were leaving them on the freeable list - unlocked - allowing them to be reclaimed: ouch. Additionally, bch2_btree_node_free_never_used() -> bch2_btree_node_hash_remove was putting it on the freelist, while bch2_btree_node_free_never_used() was putting it back on the btree update reserve list - ouch. Originally, the code was written to always keep btree nodes on a list - live or freeable - and this worked when new nodes were kept locked. But now with the cycle detector, we can't keep nodes locked that aren't tracked by the cycle detector; and this is fine as long as they're not reachable. We also have better and more robust leak detection now, with memory allocation profiling, so the original justification no longer applies. Signed-off-by: Kent Overstreet

bcachefs: Fix error handling in bch2_btree_node_prefetch()

2024-11-07T21:48:20+00:00

Signed-off-by: Kent Overstreet

bcachefs: Rework btree node pinning

2024-09-21T15:39:48+00:00

In backpointers fsck, we do a seqential scan of one btree, and check references to another: extents <-> backpointers Checking references generates random lookups, so we want to pin that btree in memory (or only a range, if it doesn't fit in ram). Previously, this was done with a simple check in the shrinker - "if btree node is in range being pinned, don't free it" - but this generated OOMs, as our shrinker wasn't well behaved if there was less memory available than expected. Instead, we now have two different shrinkers and lru lists; the second shrinker being for pinned nodes, with seeks set much higher than normal - so they can still be freed if necessary, but we'll prefer not to. Signed-off-by: Kent Overstreet

bcachefs: split up btree cache counters for live, freeable

2024-09-21T15:39:48+00:00

this is prep for introducing a second live list and shrinker for pinned nodes Signed-off-by: Kent Overstreet

bcachefs: btree cache counters should be size_t

2024-09-21T15:39:48+00:00

32 bits won't overflow any time soon, but size_t is the correct type for counting objects in memory. Signed-off-by: Kent Overstreet

bcachefs: Don't count "skipped access bit" as touched in btree cache scan

2024-09-21T15:39:48+00:00

Signed-off-by: Kent Overstreet

bcachefs: Use mm_account_reclaimed_pages() when freeing btree nodes

2024-09-21T15:39:48+00:00

When freeing in a shrinker callback, we need to notify memory reclaim, so it knows forward progress has been made. Normally this is done in e.g. slab code, but we're not freeing through slab - or rather we are, but these allocations are big, and use the kmalloc_large() path. This is really a bug in the slub code, but we're working around it here for now. Signed-off-by: Kent Overstreet

bcachefs: Use __GFP_ACCOUNT for reclaimable memory

2024-09-21T15:39:46+00:00

Signed-off-by: Kent Overstreet

bcachefs: Add pinned to btree cache not freed counters

2024-09-21T15:35:19+00:00

Signed-off-by: Kent Overstreet

bcachefs: Drop memalloc_nofs_save() in bch2_btree_node_mem_alloc()

2024-09-09T13:41:49+00:00

It's really not needed: the only locks used here are the btree cache lock, which we drop for GFP_WAIT allocations, and btree node locks - but we also drop those for GFP_WAIT allocations. Signed-off-by: Kent Overstreet