mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-11-25 03:20:53 +07:00
9630308170
Currently btrfs has a problem where it can use a ridiculous amount of RAM simply tracking free space. As free space gets fragmented, we end up with thousands of entries on an rb-tree per block group, which usually spans 1 gig of area. Since we currently don't ever flush free space cache back to disk this gets to be a bit unweildly on large fs's with lots of fragmentation. This patch solves this problem by using PAGE_SIZE bitmaps for parts of the free space cache. Initially we calculate a threshold of extent entries we can handle, which is however many extent entries we can cram into 16k of ram. The maximum amount of RAM that should ever be used to track 1 gigabyte of diskspace will be 32k of RAM, which scales much better than we did before. Once we pass the extent threshold, we start adding bitmaps and using those instead for tracking the free space. This patch also makes it so that any free space thats less than 4 * sectorsize we go ahead and put into a bitmap. This is nice since we try and allocate out of the front of a block group, so if the front of a block group is heavily fragmented and then has a huge chunk of free space at the end, we go ahead and add the fragmented areas to bitmaps and use a normal extent entry to track the big chunk at the back of the block group. I've also taken the opportunity to revamp how we search for free space. Previously we indexed free space via an offset indexed rb tree and a bytes indexed rb tree. I've dropped the bytes indexed rb tree and use only the offset indexed rb tree. This cuts the number of tree operations we were doing previously down by half, and gives us a little bit of a better allocation pattern since we will always start from a specific offset and search forward from there, instead of searching for the size we need and try and get it as close as possible to the offset we want. I've given this a healthy amount of testing pre-new format stuff, as well as post-new format stuff. I've booted up my fedora box which is installed on btrfs with this patch and ran with it for a few days without issues. I've not seen any performance regressions in any of my tests. Since the last patch Yan Zheng fixed a problem where we could have overlapping entries, so updating their offset inline would cause problems. Thanks, Signed-off-by: Josef Bacik <jbacik@redhat.com> Signed-off-by: Chris Mason <chris.mason@oracle.com> |
||
---|---|---|
.. | ||
acl.c | ||
async-thread.c | ||
async-thread.h | ||
btrfs_inode.h | ||
compat.h | ||
compression.c | ||
compression.h | ||
ctree.c | ||
ctree.h | ||
delayed-ref.c | ||
delayed-ref.h | ||
dir-item.c | ||
disk-io.c | ||
disk-io.h | ||
export.c | ||
export.h | ||
extent_io.c | ||
extent_io.h | ||
extent_map.c | ||
extent_map.h | ||
extent-tree.c | ||
file-item.c | ||
file.c | ||
free-space-cache.c | ||
free-space-cache.h | ||
hash.h | ||
inode-item.c | ||
inode-map.c | ||
inode.c | ||
ioctl.c | ||
ioctl.h | ||
Kconfig | ||
locking.c | ||
locking.h | ||
Makefile | ||
ordered-data.c | ||
ordered-data.h | ||
orphan.c | ||
print-tree.c | ||
print-tree.h | ||
ref-cache.c | ||
ref-cache.h | ||
relocation.c | ||
root-tree.c | ||
struct-funcs.c | ||
super.c | ||
sysfs.c | ||
transaction.c | ||
transaction.h | ||
tree-defrag.c | ||
tree-log.c | ||
tree-log.h | ||
version.h | ||
version.sh | ||
volumes.c | ||
volumes.h | ||
xattr.c | ||
xattr.h | ||
zlib.c |