mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2025-01-04 04:06:26 +00:00
btrfs: re-enable the extent map shrinker
Now that the extent map shrinker can only be run by a single task and runs
asynchronously as a work queue job, enable it as it can no longer cause
stalls on tasks allocating memory and entering the extent map shrinker
through the fs shrinker (implemented by btrfs_free_cached_objects()).
This is crucial to prevent exhaustion of memory due to unbounded extent
map creation, primarily with direct IO but also for buffered IO on files
with holes. This problem, for the direct IO case, was first reported in
the Link tag below. That report was added to a Link tag of the first patch
that introduced the extent map shrinker, commit 956a17d9d0
("btrfs: add
a shrinker for extent maps"), however the Link tag disappeared somehow
from the committed patch (but was included in the submitted patch to the
mailing list), so adding it below for future reference.
Link: https://lore.kernel.org/linux-btrfs/13f94633dcf04d29aaf1f0a43d42c55e@amazon.com/
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This commit is contained in:
parent
e7fa845010
commit
a8371fccf0
@ -2393,13 +2393,7 @@ static long btrfs_nr_cached_objects(struct super_block *sb, struct shrink_contro
|
||||
|
||||
trace_btrfs_extent_map_shrinker_count(fs_info, nr);
|
||||
|
||||
/*
|
||||
* Only report the real number for EXPERIMENTAL builds, as there are
|
||||
* reports of serious performance degradation caused by too frequent shrinks.
|
||||
*/
|
||||
if (IS_ENABLED(CONFIG_BTRFS_EXPERIMENTAL))
|
||||
return nr;
|
||||
return 0;
|
||||
return nr;
|
||||
}
|
||||
|
||||
static long btrfs_free_cached_objects(struct super_block *sb, struct shrink_control *sc)
|
||||
|
Loading…
Reference in New Issue
Block a user