mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-22 20:23:57 +08:00
6d6ccedd76
In examining a flame graph of time spent running xfs_scrub on various filesystems, I noticed that we spent nearly 7% of the total runtime on allocating a zeroed 65k buffer for every SCRUB_TYPE_XATTR invocation. We do this even if none of the attribute values were anywhere near 64k in size, even if there were no attribute blocks to check space on, and even if it just turns out there are no attributes at all. Therefore, rearrange the xattr buffer setup code to support reallocating with a bigger buffer and redistribute the callers of that function so that we only allocate memory just prior to needing it, and only allocate as much as we need. If we can't get memory with the ILOCK held we'll bail out with EDEADLOCK which will allocate the maximum memory. Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Brian Foster <bfoster@redhat.com> |
||
---|---|---|
.. | ||
agheader_repair.c | ||
agheader.c | ||
alloc.c | ||
attr.c | ||
attr.h | ||
bitmap.c | ||
bitmap.h | ||
bmap.c | ||
btree.c | ||
btree.h | ||
common.c | ||
common.h | ||
dabtree.c | ||
dabtree.h | ||
dir.c | ||
fscounters.c | ||
health.c | ||
health.h | ||
ialloc.c | ||
inode.c | ||
parent.c | ||
quota.c | ||
refcount.c | ||
repair.c | ||
repair.h | ||
rmap.c | ||
rtbitmap.c | ||
scrub.c | ||
scrub.h | ||
symlink.c | ||
trace.c | ||
trace.h | ||
xfs_scrub.h |