2017-12-18 03:00:59 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2008-01-29 05:19:52 +00:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2003-2006, Cluster File Systems, Inc, info@clusterfs.com
|
|
|
|
* Written by Alex Tomas <alex@clusterfs.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* mballoc.c contains the multiblocks allocation routines
|
|
|
|
*/
|
|
|
|
|
2012-02-20 22:53:02 +00:00
|
|
|
#include "ext4_jbd2.h"
|
2008-04-30 02:01:31 +00:00
|
|
|
#include "mballoc.h"
|
2012-09-05 05:31:50 +00:00
|
|
|
#include <linux/log2.h>
|
2013-02-09 21:28:20 +00:00
|
|
|
#include <linux/module.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 08:04:11 +00:00
|
|
|
#include <linux/slab.h>
|
2018-08-02 04:03:40 +00:00
|
|
|
#include <linux/nospec.h>
|
2015-05-22 21:13:32 +00:00
|
|
|
#include <linux/backing-dev.h>
|
2023-09-13 15:04:55 +00:00
|
|
|
#include <linux/freezer.h>
|
2009-06-17 15:48:11 +00:00
|
|
|
#include <trace/events/ext4.h>
|
2023-09-28 16:04:05 +00:00
|
|
|
#include <kunit/static_stub.h>
|
2009-06-17 15:48:11 +00:00
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
/*
|
|
|
|
* MUSTDO:
|
|
|
|
* - test ext4_ext_search_left() and ext4_ext_search_right()
|
|
|
|
* - search for metadata in few groups
|
|
|
|
*
|
|
|
|
* TODO v4:
|
|
|
|
* - normalization should take into account whether file is still open
|
|
|
|
* - discard preallocations if no free space left (policy?)
|
|
|
|
* - don't normalize tails
|
|
|
|
* - quota
|
|
|
|
* - reservation for superuser
|
|
|
|
*
|
|
|
|
* TODO v3:
|
|
|
|
* - bitmap read-ahead (proposed by Oleg Drokin aka green)
|
|
|
|
* - track min/max extents in each group for better group selection
|
|
|
|
* - mb_mark_used() may allocate chunk right after splitting buddy
|
|
|
|
* - tree of groups sorted by number of free blocks
|
|
|
|
* - error handling
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The allocation request involve request for multiple number of blocks
|
|
|
|
* near to the goal(block) value specified.
|
|
|
|
*
|
2009-03-31 13:11:14 +00:00
|
|
|
* During initialization phase of the allocator we decide to use the
|
|
|
|
* group preallocation or inode preallocation depending on the size of
|
|
|
|
* the file. The size of the file could be the resulting file size we
|
|
|
|
* would have after allocation, or the current file size, which ever
|
|
|
|
* is larger. If the size is less than sbi->s_mb_stream_request we
|
|
|
|
* select to use the group preallocation. The default value of
|
|
|
|
* s_mb_stream_request is 16 blocks. This can also be tuned via
|
|
|
|
* /sys/fs/ext4/<partition>/mb_stream_req. The value is represented in
|
|
|
|
* terms of number of blocks.
|
2008-01-29 05:19:52 +00:00
|
|
|
*
|
|
|
|
* The main motivation for having small file use group preallocation is to
|
2009-03-31 13:11:14 +00:00
|
|
|
* ensure that we have small files closer together on the disk.
|
2008-01-29 05:19:52 +00:00
|
|
|
*
|
2009-03-31 13:11:14 +00:00
|
|
|
* First stage the allocator looks at the inode prealloc list,
|
|
|
|
* ext4_inode_info->i_prealloc_list, which contains list of prealloc
|
|
|
|
* spaces for this particular inode. The inode prealloc space is
|
|
|
|
* represented as:
|
2008-01-29 05:19:52 +00:00
|
|
|
*
|
|
|
|
* pa_lstart -> the logical start block for this prealloc space
|
|
|
|
* pa_pstart -> the physical start block for this prealloc space
|
2011-09-09 22:48:51 +00:00
|
|
|
* pa_len -> length for this prealloc space (in clusters)
|
|
|
|
* pa_free -> free space available in this prealloc space (in clusters)
|
2008-01-29 05:19:52 +00:00
|
|
|
*
|
|
|
|
* The inode preallocation space is used looking at the _logical_ start
|
|
|
|
* block. If only the logical file block falls within the range of prealloc
|
2011-07-11 22:42:42 +00:00
|
|
|
* space we will consume the particular prealloc space. This makes sure that
|
|
|
|
* we have contiguous physical blocks representing the file blocks
|
2008-01-29 05:19:52 +00:00
|
|
|
*
|
|
|
|
* The important thing to be noted in case of inode prealloc space is that
|
|
|
|
* we don't modify the values associated to inode prealloc space except
|
|
|
|
* pa_free.
|
|
|
|
*
|
|
|
|
* If we are not able to find blocks in the inode prealloc space and if we
|
|
|
|
* have the group allocation flag set then we look at the locality group
|
2011-07-11 22:42:42 +00:00
|
|
|
* prealloc space. These are per CPU prealloc list represented as
|
2008-01-29 05:19:52 +00:00
|
|
|
*
|
|
|
|
* ext4_sb_info.s_locality_groups[smp_processor_id()]
|
|
|
|
*
|
|
|
|
* The reason for having a per cpu locality group is to reduce the contention
|
|
|
|
* between CPUs. It is possible to get scheduled at this point.
|
|
|
|
*
|
|
|
|
* The locality group prealloc space is used looking at whether we have
|
2011-03-31 01:57:33 +00:00
|
|
|
* enough free space (pa_free) within the prealloc space.
|
2008-01-29 05:19:52 +00:00
|
|
|
*
|
|
|
|
* If we can't allocate blocks via inode prealloc or/and locality group
|
|
|
|
* prealloc then we look at the buddy cache. The buddy cache is represented
|
|
|
|
* by ext4_sb_info.s_buddy_cache (struct inode) whose file offset gets
|
|
|
|
* mapped to the buddy and bitmap information regarding different
|
|
|
|
* groups. The buddy information is attached to buddy cache inode so that
|
|
|
|
* we can access them through the page cache. The information regarding
|
|
|
|
* each group is loaded via ext4_mb_load_buddy. The information involve
|
|
|
|
* block bitmap and buddy information. The information are stored in the
|
|
|
|
* inode as:
|
|
|
|
*
|
|
|
|
* { page }
|
2008-11-25 20:11:52 +00:00
|
|
|
* [ group 0 bitmap][ group 0 buddy] [group 1][ group 1]...
|
2008-01-29 05:19:52 +00:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* one block each for bitmap and buddy information. So for each group we
|
2016-04-01 12:29:48 +00:00
|
|
|
* take up 2 blocks. A page can contain blocks_per_page (PAGE_SIZE /
|
2008-01-29 05:19:52 +00:00
|
|
|
* blocksize) blocks. So it can have information regarding groups_per_page
|
|
|
|
* which is blocks_per_page/2
|
|
|
|
*
|
|
|
|
* The buddy cache inode is not stored on disk. The inode is thrown
|
|
|
|
* away when the filesystem is unmounted.
|
|
|
|
*
|
|
|
|
* We look for count number of blocks in the buddy cache. If we were able
|
|
|
|
* to locate that many free blocks we return with additional information
|
|
|
|
* regarding rest of the contiguous physical block available
|
|
|
|
*
|
|
|
|
* Before allocating blocks via buddy cache we normalize the request
|
|
|
|
* blocks. This ensure we ask for more blocks that we needed. The extra
|
|
|
|
* blocks that we get after allocation is added to the respective prealloc
|
|
|
|
* list. In case of inode preallocation we follow a list of heuristics
|
|
|
|
* based on file size. This can be found in ext4_mb_normalize_request. If
|
|
|
|
* we are doing a group prealloc we try to normalize the request to
|
2011-09-09 23:02:51 +00:00
|
|
|
* sbi->s_mb_group_prealloc. The default value of s_mb_group_prealloc is
|
|
|
|
* dependent on the cluster size; for non-bigalloc file systems, it is
|
2008-01-29 05:19:52 +00:00
|
|
|
* 512 blocks. This can be tuned via
|
2011-07-18 01:11:30 +00:00
|
|
|
* /sys/fs/ext4/<partition>/mb_group_prealloc. The value is represented in
|
2008-01-29 05:19:52 +00:00
|
|
|
* terms of number of blocks. If we have mounted the file system with -O
|
|
|
|
* stripe=<value> option the group prealloc request is normalized to the
|
2020-08-05 02:48:50 +00:00
|
|
|
* smallest multiple of the stripe value (sbi->s_stripe) which is
|
2011-07-18 01:11:30 +00:00
|
|
|
* greater than the default mb_group_prealloc.
|
2008-01-29 05:19:52 +00:00
|
|
|
*
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
* If "mb_optimize_scan" mount option is set, we maintain in memory group info
|
|
|
|
* structures in two data structures:
|
|
|
|
*
|
|
|
|
* 1) Array of largest free order lists (sbi->s_mb_largest_free_orders)
|
|
|
|
*
|
|
|
|
* Locking: sbi->s_mb_largest_free_orders_locks(array of rw locks)
|
|
|
|
*
|
|
|
|
* This is an array of lists where the index in the array represents the
|
|
|
|
* largest free order in the buddy bitmap of the participating group infos of
|
|
|
|
* that list. So, there are exactly MB_NUM_ORDERS(sb) (which means total
|
|
|
|
* number of buddy bitmap orders possible) number of lists. Group-infos are
|
|
|
|
* placed in appropriate lists.
|
|
|
|
*
|
2022-09-08 09:21:28 +00:00
|
|
|
* 2) Average fragment size lists (sbi->s_mb_avg_fragment_size)
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
*
|
2022-09-08 09:21:28 +00:00
|
|
|
* Locking: sbi->s_mb_avg_fragment_size_locks(array of rw locks)
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
*
|
2022-09-08 09:21:28 +00:00
|
|
|
* This is an array of lists where in the i-th list there are groups with
|
|
|
|
* average fragment size >= 2^i and < 2^(i+1). The average fragment size
|
|
|
|
* is computed as ext4_group_info->bb_free / ext4_group_info->bb_fragments.
|
|
|
|
* Note that we don't bother with a special list for completely empty groups
|
|
|
|
* so we only have MB_NUM_ORDERS(sb) lists.
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
*
|
|
|
|
* When "mb_optimize_scan" mount option is set, mballoc consults the above data
|
|
|
|
* structures to decide the order in which groups are to be traversed for
|
|
|
|
* fulfilling an allocation request.
|
|
|
|
*
|
2023-05-30 12:33:50 +00:00
|
|
|
* At CR_POWER2_ALIGNED , we look for groups which have the largest_free_order
|
|
|
|
* >= the order of the request. We directly look at the largest free order list
|
|
|
|
* in the data structure (1) above where largest_free_order = order of the
|
|
|
|
* request. If that list is empty, we look at remaining list in the increasing
|
|
|
|
* order of largest_free_order. This allows us to perform CR_POWER2_ALIGNED
|
|
|
|
* lookup in O(1) time.
|
|
|
|
*
|
|
|
|
* At CR_GOAL_LEN_FAST, we only consider groups where
|
|
|
|
* average fragment size > request size. So, we lookup a group which has average
|
|
|
|
* fragment size just above or equal to request size using our average fragment
|
|
|
|
* size group lists (data structure 2) in O(1) time.
|
|
|
|
*
|
|
|
|
* At CR_BEST_AVAIL_LEN, we aim to optimize allocations which can't be satisfied
|
|
|
|
* in CR_GOAL_LEN_FAST. The fact that we couldn't find a group in
|
|
|
|
* CR_GOAL_LEN_FAST suggests that there is no BG that has avg
|
|
|
|
* fragment size > goal length. So before falling to the slower
|
|
|
|
* CR_GOAL_LEN_SLOW, in CR_BEST_AVAIL_LEN we proactively trim goal length and
|
|
|
|
* then use the same fragment lists as CR_GOAL_LEN_FAST to find a BG with a big
|
|
|
|
* enough average fragment size. This increases the chances of finding a
|
|
|
|
* suitable block group in O(1) time and results in faster allocation at the
|
|
|
|
* cost of reduced size of allocation.
|
2023-05-30 12:33:49 +00:00
|
|
|
*
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
* If "mb_optimize_scan" mount option is not set, mballoc traverses groups in
|
2023-05-30 12:33:50 +00:00
|
|
|
* linear order which requires O(N) search time for each CR_POWER2_ALIGNED and
|
|
|
|
* CR_GOAL_LEN_FAST phase.
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
*
|
2011-07-18 01:11:30 +00:00
|
|
|
* The regular allocator (using the buddy cache) supports a few tunables.
|
2008-01-29 05:19:52 +00:00
|
|
|
*
|
2009-03-31 13:11:14 +00:00
|
|
|
* /sys/fs/ext4/<partition>/mb_min_to_scan
|
|
|
|
* /sys/fs/ext4/<partition>/mb_max_to_scan
|
|
|
|
* /sys/fs/ext4/<partition>/mb_order2_req
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
* /sys/fs/ext4/<partition>/mb_linear_limit
|
2008-01-29 05:19:52 +00:00
|
|
|
*
|
2009-03-31 13:11:14 +00:00
|
|
|
* The regular allocator uses buddy scan only if the request len is power of
|
2008-01-29 05:19:52 +00:00
|
|
|
* 2 blocks and the order of allocation is >= sbi->s_mb_order2_reqs. The
|
|
|
|
* value of s_mb_order2_reqs can be tuned via
|
2009-03-31 13:11:14 +00:00
|
|
|
* /sys/fs/ext4/<partition>/mb_order2_req. If the request len is equal to
|
tree-wide: fix assorted typos all over the place
That is "success", "unknown", "through", "performance", "[re|un]mapping"
, "access", "default", "reasonable", "[con]currently", "temperature"
, "channel", "[un]used", "application", "example","hierarchy", "therefore"
, "[over|under]flow", "contiguous", "threshold", "enough" and others.
Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2009-11-14 15:09:05 +00:00
|
|
|
* stripe size (sbi->s_stripe), we try to search for contiguous block in
|
2009-03-31 13:11:14 +00:00
|
|
|
* stripe size. This should result in better allocation on RAID setups. If
|
|
|
|
* not, we search in the specific group using bitmap for best extents. The
|
|
|
|
* tunable min_to_scan and max_to_scan control the behaviour here.
|
2008-01-29 05:19:52 +00:00
|
|
|
* min_to_scan indicate how long the mballoc __must__ look for a best
|
2009-03-31 13:11:14 +00:00
|
|
|
* extent and max_to_scan indicates how long the mballoc __can__ look for a
|
2008-01-29 05:19:52 +00:00
|
|
|
* best extent in the found extents. Searching for the blocks starts with
|
|
|
|
* the group specified as the goal value in allocation context via
|
|
|
|
* ac_g_ex. Each group is first checked based on the criteria whether it
|
2011-07-11 22:42:42 +00:00
|
|
|
* can be used for allocation. ext4_mb_good_group explains how the groups are
|
2008-01-29 05:19:52 +00:00
|
|
|
* checked.
|
|
|
|
*
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
* When "mb_optimize_scan" is turned on, as mentioned above, the groups may not
|
|
|
|
* get traversed linearly. That may result in subsequent allocations being not
|
|
|
|
* close to each other. And so, the underlying device may get filled up in a
|
|
|
|
* non-linear fashion. While that may not matter on non-rotational devices, for
|
|
|
|
* rotational devices that may result in higher seek times. "mb_linear_limit"
|
|
|
|
* tells mballoc how many groups mballoc should search linearly before
|
|
|
|
* performing consulting above data structures for more efficient lookups. For
|
|
|
|
* non rotational devices, this value defaults to 0 and for rotational devices
|
|
|
|
* this is set to MB_DEFAULT_LINEAR_LIMIT.
|
|
|
|
*
|
2008-01-29 05:19:52 +00:00
|
|
|
* Both the prealloc space are getting populated as above. So for the first
|
|
|
|
* request we will hit the buddy cache which will result in this prealloc
|
|
|
|
* space getting filled. The prealloc space is then later used for the
|
|
|
|
* subsequent request.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* mballoc operates on the following data:
|
|
|
|
* - on-disk bitmap
|
|
|
|
* - in-core buddy (actually includes buddy and bitmap)
|
|
|
|
* - preallocation descriptors (PAs)
|
|
|
|
*
|
|
|
|
* there are two types of preallocations:
|
|
|
|
* - inode
|
|
|
|
* assiged to specific inode and can be used for this inode only.
|
|
|
|
* it describes part of inode's space preallocated to specific
|
|
|
|
* physical blocks. any block from that preallocated can be used
|
|
|
|
* independent. the descriptor just tracks number of blocks left
|
|
|
|
* unused. so, before taking some block from descriptor, one must
|
|
|
|
* make sure corresponded logical block isn't allocated yet. this
|
|
|
|
* also means that freeing any block within descriptor's range
|
|
|
|
* must discard all preallocated blocks.
|
|
|
|
* - locality group
|
|
|
|
* assigned to specific locality group which does not translate to
|
|
|
|
* permanent set of inodes: inode can join and leave group. space
|
|
|
|
* from this type of preallocation can be used for any inode. thus
|
|
|
|
* it's consumed from the beginning to the end.
|
|
|
|
*
|
|
|
|
* relation between them can be expressed as:
|
|
|
|
* in-core buddy = on-disk bitmap + preallocation descriptors
|
|
|
|
*
|
|
|
|
* this mean blocks mballoc considers used are:
|
|
|
|
* - allocated blocks (persistent)
|
|
|
|
* - preallocated blocks (non-persistent)
|
|
|
|
*
|
|
|
|
* consistency in mballoc world means that at any time a block is either
|
|
|
|
* free or used in ALL structures. notice: "any time" should not be read
|
|
|
|
* literally -- time is discrete and delimited by locks.
|
|
|
|
*
|
|
|
|
* to keep it simple, we don't use block numbers, instead we count number of
|
|
|
|
* blocks: how many blocks marked used/free in on-disk bitmap, buddy and PA.
|
|
|
|
*
|
|
|
|
* all operations can be expressed as:
|
|
|
|
* - init buddy: buddy = on-disk + PAs
|
|
|
|
* - new PA: buddy += N; PA = N
|
|
|
|
* - use inode PA: on-disk += N; PA -= N
|
|
|
|
* - discard inode PA buddy -= on-disk - PA; PA = 0
|
|
|
|
* - use locality group PA on-disk += N; PA -= N
|
|
|
|
* - discard locality group PA buddy -= PA; PA = 0
|
|
|
|
* note: 'buddy -= on-disk - PA' is used to show that on-disk bitmap
|
|
|
|
* is used in real operation because we can't know actual used
|
|
|
|
* bits from PA, only from on-disk bitmap
|
|
|
|
*
|
|
|
|
* if we follow this strict logic, then all operations above should be atomic.
|
|
|
|
* given some of them can block, we'd have to use something like semaphores
|
|
|
|
* killing performance on high-end SMP hardware. let's try to relax it using
|
|
|
|
* the following knowledge:
|
|
|
|
* 1) if buddy is referenced, it's already initialized
|
|
|
|
* 2) while block is used in buddy and the buddy is referenced,
|
|
|
|
* nobody can re-allocate that block
|
|
|
|
* 3) we work on bitmaps and '+' actually means 'set bits'. if on-disk has
|
|
|
|
* bit set and PA claims same block, it's OK. IOW, one can set bit in
|
|
|
|
* on-disk bitmap if buddy has same bit set or/and PA covers corresponded
|
|
|
|
* block
|
|
|
|
*
|
|
|
|
* so, now we're building a concurrency table:
|
|
|
|
* - init buddy vs.
|
|
|
|
* - new PA
|
|
|
|
* blocks for PA are allocated in the buddy, buddy must be referenced
|
|
|
|
* until PA is linked to allocation group to avoid concurrent buddy init
|
|
|
|
* - use inode PA
|
|
|
|
* we need to make sure that either on-disk bitmap or PA has uptodate data
|
|
|
|
* given (3) we care that PA-=N operation doesn't interfere with init
|
|
|
|
* - discard inode PA
|
|
|
|
* the simplest way would be to have buddy initialized by the discard
|
|
|
|
* - use locality group PA
|
|
|
|
* again PA-=N must be serialized with init
|
|
|
|
* - discard locality group PA
|
|
|
|
* the simplest way would be to have buddy initialized by the discard
|
|
|
|
* - new PA vs.
|
|
|
|
* - use inode PA
|
|
|
|
* i_data_sem serializes them
|
|
|
|
* - discard inode PA
|
|
|
|
* discard process must wait until PA isn't used by another process
|
|
|
|
* - use locality group PA
|
|
|
|
* some mutex should serialize them
|
|
|
|
* - discard locality group PA
|
|
|
|
* discard process must wait until PA isn't used by another process
|
|
|
|
* - use inode PA
|
|
|
|
* - use inode PA
|
|
|
|
* i_data_sem or another mutex should serializes them
|
|
|
|
* - discard inode PA
|
|
|
|
* discard process must wait until PA isn't used by another process
|
|
|
|
* - use locality group PA
|
|
|
|
* nothing wrong here -- they're different PAs covering different blocks
|
|
|
|
* - discard locality group PA
|
|
|
|
* discard process must wait until PA isn't used by another process
|
|
|
|
*
|
|
|
|
* now we're ready to make few consequences:
|
|
|
|
* - PA is referenced and while it is no discard is possible
|
|
|
|
* - PA is referenced until block isn't marked in on-disk bitmap
|
|
|
|
* - PA changes only after on-disk bitmap
|
|
|
|
* - discard must not compete with init. either init is done before
|
|
|
|
* any discard or they're serialized somehow
|
|
|
|
* - buddy init as sum of on-disk bitmap and PAs is done atomically
|
|
|
|
*
|
|
|
|
* a special case when we've used PA to emptiness. no need to modify buddy
|
|
|
|
* in this case, but we should care about concurrent init
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Logic in few words:
|
|
|
|
*
|
|
|
|
* - allocation:
|
|
|
|
* load group
|
|
|
|
* find blocks
|
|
|
|
* mark bits in on-disk bitmap
|
|
|
|
* release group
|
|
|
|
*
|
|
|
|
* - use preallocation:
|
|
|
|
* find proper PA (per-inode or group)
|
|
|
|
* load group
|
|
|
|
* mark bits in on-disk bitmap
|
|
|
|
* release group
|
|
|
|
* release PA
|
|
|
|
*
|
|
|
|
* - free:
|
|
|
|
* load group
|
|
|
|
* mark bits in on-disk bitmap
|
|
|
|
* release group
|
|
|
|
*
|
|
|
|
* - discard preallocations in group:
|
|
|
|
* mark PAs deleted
|
|
|
|
* move them onto local list
|
|
|
|
* load on-disk bitmap
|
|
|
|
* load group
|
|
|
|
* remove PA from object (inode or locality group)
|
|
|
|
* mark free blocks in-core
|
|
|
|
*
|
|
|
|
* - discard inode's preallocations:
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Locking rules
|
|
|
|
*
|
|
|
|
* Locks:
|
|
|
|
* - bitlock on a group (group)
|
|
|
|
* - object (inode/locality) (object)
|
|
|
|
* - per-pa lock (pa)
|
2023-05-30 12:33:50 +00:00
|
|
|
* - cr_power2_aligned lists lock (cr_power2_aligned)
|
|
|
|
* - cr_goal_len_fast lists lock (cr_goal_len_fast)
|
2008-01-29 05:19:52 +00:00
|
|
|
*
|
|
|
|
* Paths:
|
|
|
|
* - new pa
|
|
|
|
* object
|
|
|
|
* group
|
|
|
|
*
|
|
|
|
* - find and use pa:
|
|
|
|
* pa
|
|
|
|
*
|
|
|
|
* - release consumed pa:
|
|
|
|
* pa
|
|
|
|
* group
|
|
|
|
* object
|
|
|
|
*
|
|
|
|
* - generate in-core bitmap:
|
|
|
|
* group
|
|
|
|
* pa
|
|
|
|
*
|
|
|
|
* - discard all for given object (inode, locality group):
|
|
|
|
* object
|
|
|
|
* pa
|
|
|
|
* group
|
|
|
|
*
|
|
|
|
* - discard all for given group:
|
|
|
|
* group
|
|
|
|
* pa
|
|
|
|
* group
|
|
|
|
* object
|
|
|
|
*
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
* - allocation path (ext4_mb_regular_allocator)
|
|
|
|
* group
|
2023-05-30 12:33:50 +00:00
|
|
|
* cr_power2_aligned/cr_goal_len_fast
|
2008-01-29 05:19:52 +00:00
|
|
|
*/
|
2008-11-25 20:11:52 +00:00
|
|
|
static struct kmem_cache *ext4_pspace_cachep;
|
|
|
|
static struct kmem_cache *ext4_ac_cachep;
|
2012-02-20 22:53:02 +00:00
|
|
|
static struct kmem_cache *ext4_free_data_cachep;
|
2010-10-28 01:29:12 +00:00
|
|
|
|
|
|
|
/* We create slab caches for groupinfo data structures based on the
|
|
|
|
* superblock block size. There will be one per mounted filesystem for
|
|
|
|
* each unique s_blocksize_bits */
|
2011-02-12 13:12:18 +00:00
|
|
|
#define NR_GRPINFO_CACHES 8
|
2010-10-28 01:29:12 +00:00
|
|
|
static struct kmem_cache *ext4_groupinfo_caches[NR_GRPINFO_CACHES];
|
|
|
|
|
2017-04-30 03:47:50 +00:00
|
|
|
static const char * const ext4_groupinfo_slab_names[NR_GRPINFO_CACHES] = {
|
2011-02-12 13:12:18 +00:00
|
|
|
"ext4_groupinfo_1k", "ext4_groupinfo_2k", "ext4_groupinfo_4k",
|
|
|
|
"ext4_groupinfo_8k", "ext4_groupinfo_16k", "ext4_groupinfo_32k",
|
|
|
|
"ext4_groupinfo_64k", "ext4_groupinfo_128k"
|
|
|
|
};
|
|
|
|
|
2008-11-25 20:11:52 +00:00
|
|
|
static void ext4_mb_generate_from_pa(struct super_block *sb, void *bitmap,
|
|
|
|
ext4_group_t group);
|
2020-05-20 06:40:32 +00:00
|
|
|
static void ext4_mb_new_preallocation(struct ext4_allocation_context *ac);
|
2008-11-25 20:11:52 +00:00
|
|
|
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
static bool ext4_mb_good_group(struct ext4_allocation_context *ac,
|
2023-05-30 12:33:42 +00:00
|
|
|
ext4_group_t group, enum criteria cr);
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
|
2021-07-24 07:41:23 +00:00
|
|
|
static int ext4_try_to_trim_range(struct super_block *sb,
|
|
|
|
struct ext4_buddy *e4b, ext4_grpblk_t start,
|
|
|
|
ext4_grpblk_t max, ext4_grpblk_t minblocks);
|
|
|
|
|
ext4: mballoc: introduce pcpu seqcnt for freeing PA to improve ENOSPC handling
There could be a race in function ext4_mb_discard_group_preallocations()
where the 1st thread may iterate through group's bb_prealloc_list and
remove all the PAs and add to function's local list head.
Now if the 2nd thread comes in to discard the group preallocations,
it will see that the group->bb_prealloc_list is empty and will return 0.
Consider for a case where we have less number of groups
(for e.g. just group 0),
this may even return an -ENOSPC error from ext4_mb_new_blocks()
(where we call for ext4_mb_discard_group_preallocations()).
But that is wrong, since 2nd thread should have waited for 1st thread
to release all the PAs and should have retried for allocation.
Since 1st thread was anyway going to discard the PAs.
The algorithm using this percpu seq counter goes below:
1. We sample the percpu discard_pa_seq counter before trying for block
allocation in ext4_mb_new_blocks().
2. We increment this percpu discard_pa_seq counter when we either allocate
or free these blocks i.e. while marking those blocks as used/free in
mb_mark_used()/mb_free_blocks().
3. We also increment this percpu seq counter when we successfully identify
that the bb_prealloc_list is not empty and hence proceed for discarding
of those PAs inside ext4_mb_discard_group_preallocations().
Now to make sure that the regular fast path of block allocation is not
affected, as a small optimization we only sample the percpu seq counter
on that cpu. Only when the block allocation fails and when freed blocks
found were 0, that is when we sample percpu seq counter for all cpus using
below function ext4_get_discard_pa_seq_sum(). This happens after making
sure that all the PAs on grp->bb_prealloc_list got freed or if it's empty.
It can be well argued that why don't just check for grp->bb_free to
see if there are any free blocks to be allocated. So here are the two
concerns which were discussed:-
1. If for some reason the blocks available in the group are not
appropriate for allocation logic (say for e.g.
EXT4_MB_HINT_GOAL_ONLY, although this is not yet implemented), then
the retry logic may result into infinte looping since grp->bb_free is
non-zero.
2. Also before preallocation was clubbed with block allocation with the
same ext4_lock_group() held, there were lot of races where grp->bb_free
could not be reliably relied upon.
Due to above, this patch considers discard_pa_seq logic to determine if
we should retry for block allocation. Say if there are are n threads
trying for block allocation and none of those could allocate or discard
any of the blocks, then all of those n threads will fail the block
allocation and return -ENOSPC error. (Since the seq counter for all of
those will match as no block allocation/discard was done during that
duration).
Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
Link: https://lore.kernel.org/r/7f254686903b87c419d798742fd9a1be34f0657b.1589955723.git.riteshh@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2020-05-20 06:40:34 +00:00
|
|
|
/*
|
|
|
|
* The algorithm using this percpu seq counter goes below:
|
|
|
|
* 1. We sample the percpu discard_pa_seq counter before trying for block
|
|
|
|
* allocation in ext4_mb_new_blocks().
|
|
|
|
* 2. We increment this percpu discard_pa_seq counter when we either allocate
|
|
|
|
* or free these blocks i.e. while marking those blocks as used/free in
|
|
|
|
* mb_mark_used()/mb_free_blocks().
|
|
|
|
* 3. We also increment this percpu seq counter when we successfully identify
|
|
|
|
* that the bb_prealloc_list is not empty and hence proceed for discarding
|
|
|
|
* of those PAs inside ext4_mb_discard_group_preallocations().
|
|
|
|
*
|
|
|
|
* Now to make sure that the regular fast path of block allocation is not
|
|
|
|
* affected, as a small optimization we only sample the percpu seq counter
|
|
|
|
* on that cpu. Only when the block allocation fails and when freed blocks
|
|
|
|
* found were 0, that is when we sample percpu seq counter for all cpus using
|
|
|
|
* below function ext4_get_discard_pa_seq_sum(). This happens after making
|
|
|
|
* sure that all the PAs on grp->bb_prealloc_list got freed or if it's empty.
|
|
|
|
*/
|
|
|
|
static DEFINE_PER_CPU(u64, discard_pa_seq);
|
|
|
|
static inline u64 ext4_get_discard_pa_seq_sum(void)
|
|
|
|
{
|
|
|
|
int __cpu;
|
|
|
|
u64 __seq = 0;
|
|
|
|
|
|
|
|
for_each_possible_cpu(__cpu)
|
|
|
|
__seq += per_cpu(discard_pa_seq, __cpu);
|
|
|
|
return __seq;
|
|
|
|
}
|
|
|
|
|
2008-02-23 06:38:34 +00:00
|
|
|
static inline void *mb_correct_addr_and_bit(int *bit, void *addr)
|
|
|
|
{
|
2008-01-29 05:19:52 +00:00
|
|
|
#if BITS_PER_LONG == 64
|
2008-02-23 06:38:34 +00:00
|
|
|
*bit += ((unsigned long) addr & 7UL) << 3;
|
|
|
|
addr = (void *) ((unsigned long) addr & ~7UL);
|
2008-01-29 05:19:52 +00:00
|
|
|
#elif BITS_PER_LONG == 32
|
2008-02-23 06:38:34 +00:00
|
|
|
*bit += ((unsigned long) addr & 3UL) << 3;
|
|
|
|
addr = (void *) ((unsigned long) addr & ~3UL);
|
2008-01-29 05:19:52 +00:00
|
|
|
#else
|
|
|
|
#error "how many bits you are?!"
|
|
|
|
#endif
|
2008-02-23 06:38:34 +00:00
|
|
|
return addr;
|
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
static inline int mb_test_bit(int bit, void *addr)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* ext4_test_bit on architecture like powerpc
|
|
|
|
* needs unsigned long aligned address
|
|
|
|
*/
|
2008-02-23 06:38:34 +00:00
|
|
|
addr = mb_correct_addr_and_bit(&bit, addr);
|
2008-01-29 05:19:52 +00:00
|
|
|
return ext4_test_bit(bit, addr);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void mb_set_bit(int bit, void *addr)
|
|
|
|
{
|
2008-02-23 06:38:34 +00:00
|
|
|
addr = mb_correct_addr_and_bit(&bit, addr);
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_set_bit(bit, addr);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void mb_clear_bit(int bit, void *addr)
|
|
|
|
{
|
2008-02-23 06:38:34 +00:00
|
|
|
addr = mb_correct_addr_and_bit(&bit, addr);
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_clear_bit(bit, addr);
|
|
|
|
}
|
|
|
|
|
2013-04-09 16:22:29 +00:00
|
|
|
static inline int mb_test_and_clear_bit(int bit, void *addr)
|
|
|
|
{
|
|
|
|
addr = mb_correct_addr_and_bit(&bit, addr);
|
|
|
|
return ext4_test_and_clear_bit(bit, addr);
|
|
|
|
}
|
|
|
|
|
2008-02-23 06:38:34 +00:00
|
|
|
static inline int mb_find_next_zero_bit(void *addr, int max, int start)
|
|
|
|
{
|
2008-07-11 23:27:31 +00:00
|
|
|
int fix = 0, ret, tmpmax;
|
2008-02-23 06:38:34 +00:00
|
|
|
addr = mb_correct_addr_and_bit(&fix, addr);
|
2008-07-11 23:27:31 +00:00
|
|
|
tmpmax = max + fix;
|
2008-02-23 06:38:34 +00:00
|
|
|
start += fix;
|
|
|
|
|
2008-07-11 23:27:31 +00:00
|
|
|
ret = ext4_find_next_zero_bit(addr, tmpmax, start) - fix;
|
|
|
|
if (ret > max)
|
|
|
|
return max;
|
|
|
|
return ret;
|
2008-02-23 06:38:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline int mb_find_next_bit(void *addr, int max, int start)
|
|
|
|
{
|
2008-07-11 23:27:31 +00:00
|
|
|
int fix = 0, ret, tmpmax;
|
2008-02-23 06:38:34 +00:00
|
|
|
addr = mb_correct_addr_and_bit(&fix, addr);
|
2008-07-11 23:27:31 +00:00
|
|
|
tmpmax = max + fix;
|
2008-02-23 06:38:34 +00:00
|
|
|
start += fix;
|
|
|
|
|
2008-07-11 23:27:31 +00:00
|
|
|
ret = ext4_find_next_bit(addr, tmpmax, start) - fix;
|
|
|
|
if (ret > max)
|
|
|
|
return max;
|
|
|
|
return ret;
|
2008-02-23 06:38:34 +00:00
|
|
|
}
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
static void *mb_find_buddy(struct ext4_buddy *e4b, int order, int *max)
|
|
|
|
{
|
|
|
|
char *bb;
|
|
|
|
|
2012-02-20 22:54:06 +00:00
|
|
|
BUG_ON(e4b->bd_bitmap == e4b->bd_buddy);
|
2008-01-29 05:19:52 +00:00
|
|
|
BUG_ON(max == NULL);
|
|
|
|
|
|
|
|
if (order > e4b->bd_blkbits + 1) {
|
|
|
|
*max = 0;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* at order 0 we see each particular block */
|
2011-02-24 17:51:59 +00:00
|
|
|
if (order == 0) {
|
|
|
|
*max = 1 << (e4b->bd_blkbits + 3);
|
2012-02-20 22:54:06 +00:00
|
|
|
return e4b->bd_bitmap;
|
2011-02-24 17:51:59 +00:00
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2012-02-20 22:54:06 +00:00
|
|
|
bb = e4b->bd_buddy + EXT4_SB(e4b->bd_sb)->s_mb_offsets[order];
|
2008-01-29 05:19:52 +00:00
|
|
|
*max = EXT4_SB(e4b->bd_sb)->s_mb_maxs[order];
|
|
|
|
|
|
|
|
return bb;
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef DOUBLE_CHECK
|
|
|
|
static void mb_free_blocks_double(struct inode *inode, struct ext4_buddy *e4b,
|
|
|
|
int first, int count)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
struct super_block *sb = e4b->bd_sb;
|
|
|
|
|
|
|
|
if (unlikely(e4b->bd_info->bb_bitmap == NULL))
|
|
|
|
return;
|
2009-05-15 12:33:18 +00:00
|
|
|
assert_spin_locked(ext4_group_lock_ptr(sb, e4b->bd_group));
|
2008-01-29 05:19:52 +00:00
|
|
|
for (i = 0; i < count; i++) {
|
|
|
|
if (!mb_test_bit(first + i, e4b->bd_info->bb_bitmap)) {
|
|
|
|
ext4_fsblk_t blocknr;
|
2010-03-04 04:53:39 +00:00
|
|
|
|
|
|
|
blocknr = ext4_group_first_block_no(sb, e4b->bd_group);
|
2011-09-09 22:48:51 +00:00
|
|
|
blocknr += EXT4_C2B(EXT4_SB(sb), first + i);
|
2024-01-04 14:20:40 +00:00
|
|
|
ext4_mark_group_bitmap_corrupted(sb, e4b->bd_group,
|
|
|
|
EXT4_GROUP_INFO_BBITMAP_CORRUPT);
|
2009-01-06 03:19:52 +00:00
|
|
|
ext4_grp_locked_error(sb, e4b->bd_group,
|
2010-06-29 16:54:28 +00:00
|
|
|
inode ? inode->i_ino : 0,
|
|
|
|
blocknr,
|
|
|
|
"freeing block already freed "
|
|
|
|
"(bit %u)",
|
|
|
|
first + i);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
mb_clear_bit(first + i, e4b->bd_info->bb_bitmap);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void mb_mark_used_double(struct ext4_buddy *e4b, int first, int count)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (unlikely(e4b->bd_info->bb_bitmap == NULL))
|
|
|
|
return;
|
2009-05-15 12:33:18 +00:00
|
|
|
assert_spin_locked(ext4_group_lock_ptr(e4b->bd_sb, e4b->bd_group));
|
2008-01-29 05:19:52 +00:00
|
|
|
for (i = 0; i < count; i++) {
|
|
|
|
BUG_ON(mb_test_bit(first + i, e4b->bd_info->bb_bitmap));
|
|
|
|
mb_set_bit(first + i, e4b->bd_info->bb_bitmap);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void mb_cmp_bitmaps(struct ext4_buddy *e4b, void *bitmap)
|
|
|
|
{
|
2020-05-10 06:24:49 +00:00
|
|
|
if (unlikely(e4b->bd_info->bb_bitmap == NULL))
|
|
|
|
return;
|
2008-01-29 05:19:52 +00:00
|
|
|
if (memcmp(e4b->bd_info->bb_bitmap, bitmap, e4b->bd_sb->s_blocksize)) {
|
|
|
|
unsigned char *b1, *b2;
|
|
|
|
int i;
|
|
|
|
b1 = (unsigned char *) e4b->bd_info->bb_bitmap;
|
|
|
|
b2 = (unsigned char *) bitmap;
|
|
|
|
for (i = 0; i < e4b->bd_sb->s_blocksize; i++) {
|
|
|
|
if (b1[i] != b2[i]) {
|
2011-08-01 21:41:35 +00:00
|
|
|
ext4_msg(e4b->bd_sb, KERN_ERR,
|
|
|
|
"corruption in group %u "
|
|
|
|
"at byte %u(%u): %x in copy != %x "
|
|
|
|
"on disk/prealloc",
|
|
|
|
e4b->bd_group, i, i * 8, b1[i], b2[i]);
|
2008-01-29 05:19:52 +00:00
|
|
|
BUG();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-05-10 06:24:48 +00:00
|
|
|
static void mb_group_bb_bitmap_alloc(struct super_block *sb,
|
|
|
|
struct ext4_group_info *grp, ext4_group_t group)
|
|
|
|
{
|
|
|
|
struct buffer_head *bh;
|
|
|
|
|
|
|
|
grp->bb_bitmap = kmalloc(sb->s_blocksize, GFP_NOFS);
|
2020-05-10 06:24:49 +00:00
|
|
|
if (!grp->bb_bitmap)
|
|
|
|
return;
|
2020-05-10 06:24:48 +00:00
|
|
|
|
|
|
|
bh = ext4_read_block_bitmap(sb, group);
|
2020-05-10 06:24:49 +00:00
|
|
|
if (IS_ERR_OR_NULL(bh)) {
|
|
|
|
kfree(grp->bb_bitmap);
|
|
|
|
grp->bb_bitmap = NULL;
|
|
|
|
return;
|
|
|
|
}
|
2020-05-10 06:24:48 +00:00
|
|
|
|
|
|
|
memcpy(grp->bb_bitmap, bh->b_data, sb->s_blocksize);
|
|
|
|
put_bh(bh);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void mb_group_bb_bitmap_free(struct ext4_group_info *grp)
|
|
|
|
{
|
|
|
|
kfree(grp->bb_bitmap);
|
|
|
|
}
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
#else
|
|
|
|
static inline void mb_free_blocks_double(struct inode *inode,
|
|
|
|
struct ext4_buddy *e4b, int first, int count)
|
|
|
|
{
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
static inline void mb_mark_used_double(struct ext4_buddy *e4b,
|
|
|
|
int first, int count)
|
|
|
|
{
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
static inline void mb_cmp_bitmaps(struct ext4_buddy *e4b, void *bitmap)
|
|
|
|
{
|
|
|
|
return;
|
|
|
|
}
|
2020-05-10 06:24:48 +00:00
|
|
|
|
|
|
|
static inline void mb_group_bb_bitmap_alloc(struct super_block *sb,
|
|
|
|
struct ext4_group_info *grp, ext4_group_t group)
|
|
|
|
{
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void mb_group_bb_bitmap_free(struct ext4_group_info *grp)
|
|
|
|
{
|
|
|
|
return;
|
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef AGGRESSIVE_CHECK
|
|
|
|
|
|
|
|
#define MB_CHECK_ASSERT(assert) \
|
|
|
|
do { \
|
|
|
|
if (!(assert)) { \
|
|
|
|
printk(KERN_EMERG \
|
|
|
|
"Assertion failure in %s() at %s:%d: \"%s\"\n", \
|
|
|
|
function, file, line, # assert); \
|
|
|
|
BUG(); \
|
|
|
|
} \
|
|
|
|
} while (0)
|
|
|
|
|
2024-01-05 09:20:54 +00:00
|
|
|
static void __mb_check_buddy(struct ext4_buddy *e4b, char *file,
|
2008-01-29 05:19:52 +00:00
|
|
|
const char *function, int line)
|
|
|
|
{
|
|
|
|
struct super_block *sb = e4b->bd_sb;
|
|
|
|
int order = e4b->bd_blkbits + 1;
|
|
|
|
int max;
|
|
|
|
int max2;
|
|
|
|
int i;
|
|
|
|
int j;
|
|
|
|
int k;
|
|
|
|
int count;
|
|
|
|
struct ext4_group_info *grp;
|
|
|
|
int fragments = 0;
|
|
|
|
int fstart;
|
|
|
|
struct list_head *cur;
|
|
|
|
void *buddy;
|
|
|
|
void *buddy2;
|
|
|
|
|
2020-09-28 11:36:35 +00:00
|
|
|
if (e4b->bd_info->bb_check_counter++ % 10)
|
2024-01-05 09:20:54 +00:00
|
|
|
return;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
while (order > 1) {
|
|
|
|
buddy = mb_find_buddy(e4b, order, &max);
|
|
|
|
MB_CHECK_ASSERT(buddy);
|
|
|
|
buddy2 = mb_find_buddy(e4b, order - 1, &max2);
|
|
|
|
MB_CHECK_ASSERT(buddy2);
|
|
|
|
MB_CHECK_ASSERT(buddy != buddy2);
|
|
|
|
MB_CHECK_ASSERT(max * 2 == max2);
|
|
|
|
|
|
|
|
count = 0;
|
|
|
|
for (i = 0; i < max; i++) {
|
|
|
|
|
|
|
|
if (mb_test_bit(i, buddy)) {
|
2022-04-04 15:22:43 +00:00
|
|
|
/* only single bit in buddy2 may be 0 */
|
2008-01-29 05:19:52 +00:00
|
|
|
if (!mb_test_bit(i << 1, buddy2)) {
|
|
|
|
MB_CHECK_ASSERT(
|
|
|
|
mb_test_bit((i<<1)+1, buddy2));
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2011-10-26 12:48:54 +00:00
|
|
|
/* both bits in buddy2 must be 1 */
|
2008-01-29 05:19:52 +00:00
|
|
|
MB_CHECK_ASSERT(mb_test_bit(i << 1, buddy2));
|
|
|
|
MB_CHECK_ASSERT(mb_test_bit((i << 1) + 1, buddy2));
|
|
|
|
|
|
|
|
for (j = 0; j < (1 << order); j++) {
|
|
|
|
k = (i * (1 << order)) + j;
|
|
|
|
MB_CHECK_ASSERT(
|
2012-02-20 22:54:06 +00:00
|
|
|
!mb_test_bit(k, e4b->bd_bitmap));
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
count++;
|
|
|
|
}
|
|
|
|
MB_CHECK_ASSERT(e4b->bd_info->bb_counters[order] == count);
|
|
|
|
order--;
|
|
|
|
}
|
|
|
|
|
|
|
|
fstart = -1;
|
|
|
|
buddy = mb_find_buddy(e4b, 0, &max);
|
|
|
|
for (i = 0; i < max; i++) {
|
|
|
|
if (!mb_test_bit(i, buddy)) {
|
|
|
|
MB_CHECK_ASSERT(i >= e4b->bd_info->bb_first_free);
|
|
|
|
if (fstart == -1) {
|
|
|
|
fragments++;
|
|
|
|
fstart = i;
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
fstart = -1;
|
|
|
|
/* check used bits only */
|
|
|
|
for (j = 0; j < e4b->bd_blkbits + 1; j++) {
|
|
|
|
buddy2 = mb_find_buddy(e4b, j, &max2);
|
|
|
|
k = i >> j;
|
|
|
|
MB_CHECK_ASSERT(k < max2);
|
|
|
|
MB_CHECK_ASSERT(mb_test_bit(k, buddy2));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
MB_CHECK_ASSERT(!EXT4_MB_GRP_NEED_INIT(e4b->bd_info));
|
|
|
|
MB_CHECK_ASSERT(e4b->bd_info->bb_fragments == fragments);
|
|
|
|
|
|
|
|
grp = ext4_get_group_info(sb, e4b->bd_group);
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
if (!grp)
|
2024-01-05 09:20:54 +00:00
|
|
|
return;
|
2008-01-29 05:19:52 +00:00
|
|
|
list_for_each(cur, &grp->bb_prealloc_list) {
|
|
|
|
ext4_group_t groupnr;
|
|
|
|
struct ext4_prealloc_space *pa;
|
2008-04-30 01:59:59 +00:00
|
|
|
pa = list_entry(cur, struct ext4_prealloc_space, pa_group_list);
|
|
|
|
ext4_get_group_no_and_offset(sb, pa->pa_pstart, &groupnr, &k);
|
2008-01-29 05:19:52 +00:00
|
|
|
MB_CHECK_ASSERT(groupnr == e4b->bd_group);
|
2008-04-30 01:59:59 +00:00
|
|
|
for (i = 0; i < pa->pa_len; i++)
|
2008-01-29 05:19:52 +00:00
|
|
|
MB_CHECK_ASSERT(mb_test_bit(k + i, buddy));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#undef MB_CHECK_ASSERT
|
|
|
|
#define mb_check_buddy(e4b) __mb_check_buddy(e4b, \
|
2008-04-17 14:38:59 +00:00
|
|
|
__FILE__, __func__, __LINE__)
|
2008-01-29 05:19:52 +00:00
|
|
|
#else
|
|
|
|
#define mb_check_buddy(e4b)
|
|
|
|
#endif
|
|
|
|
|
2011-02-24 18:24:25 +00:00
|
|
|
/*
|
|
|
|
* Divide blocks started from @first with length @len into
|
|
|
|
* smaller chunks with power of 2 blocks.
|
|
|
|
* Clear the bits in bitmap which the blocks of the chunk(s) covered,
|
|
|
|
* then increase bb_counters[] for corresponded chunk size.
|
|
|
|
*/
|
2008-01-29 05:19:52 +00:00
|
|
|
static void ext4_mb_mark_free_simple(struct super_block *sb,
|
2009-08-26 02:36:45 +00:00
|
|
|
void *buddy, ext4_grpblk_t first, ext4_grpblk_t len,
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_group_info *grp)
|
|
|
|
{
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
2009-08-26 02:36:45 +00:00
|
|
|
ext4_grpblk_t min;
|
|
|
|
ext4_grpblk_t max;
|
|
|
|
ext4_grpblk_t chunk;
|
2016-11-15 02:04:37 +00:00
|
|
|
unsigned int border;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2011-09-09 22:38:51 +00:00
|
|
|
BUG_ON(len > EXT4_CLUSTERS_PER_GROUP(sb));
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
border = 2 << sb->s_blocksize_bits;
|
|
|
|
|
|
|
|
while (len > 0) {
|
|
|
|
/* find how many blocks can be covered since this position */
|
|
|
|
max = ffs(first | border) - 1;
|
|
|
|
|
|
|
|
/* find how many blocks of power 2 we need to mark */
|
|
|
|
min = fls(len) - 1;
|
|
|
|
|
|
|
|
if (max < min)
|
|
|
|
min = max;
|
|
|
|
chunk = 1 << min;
|
|
|
|
|
|
|
|
/* mark multiblock chunks only */
|
|
|
|
grp->bb_counters[min]++;
|
|
|
|
if (min > 0)
|
|
|
|
mb_clear_bit(first >> min,
|
|
|
|
buddy + sbi->s_mb_offsets[min]);
|
|
|
|
|
|
|
|
len -= chunk;
|
|
|
|
first += chunk;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-09-08 09:21:28 +00:00
|
|
|
static int mb_avg_fragment_size_order(struct super_block *sb, ext4_grpblk_t len)
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
{
|
2022-09-08 09:21:28 +00:00
|
|
|
int order;
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
|
2022-09-08 09:21:28 +00:00
|
|
|
/*
|
|
|
|
* We don't bother with a special lists groups with only 1 block free
|
|
|
|
* extents and for completely empty groups.
|
|
|
|
*/
|
|
|
|
order = fls(len) - 2;
|
|
|
|
if (order < 0)
|
|
|
|
return 0;
|
|
|
|
if (order == MB_NUM_ORDERS(sb))
|
|
|
|
order--;
|
2024-03-19 11:33:20 +00:00
|
|
|
if (WARN_ON_ONCE(order > MB_NUM_ORDERS(sb)))
|
|
|
|
order = MB_NUM_ORDERS(sb) - 1;
|
2022-09-08 09:21:28 +00:00
|
|
|
return order;
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
}
|
|
|
|
|
2022-09-08 09:21:28 +00:00
|
|
|
/* Move group to appropriate avg_fragment_size list */
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
static void
|
|
|
|
mb_update_avg_fragment_size(struct super_block *sb, struct ext4_group_info *grp)
|
|
|
|
{
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
2022-09-08 09:21:28 +00:00
|
|
|
int new_order;
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
|
2024-01-04 14:20:37 +00:00
|
|
|
if (!test_opt2(sb, MB_OPTIMIZE_SCAN) || grp->bb_fragments == 0)
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
return;
|
|
|
|
|
2022-09-08 09:21:28 +00:00
|
|
|
new_order = mb_avg_fragment_size_order(sb,
|
|
|
|
grp->bb_free / grp->bb_fragments);
|
|
|
|
if (new_order == grp->bb_avg_fragment_size_order)
|
|
|
|
return;
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
|
2022-09-08 09:21:28 +00:00
|
|
|
if (grp->bb_avg_fragment_size_order != -1) {
|
|
|
|
write_lock(&sbi->s_mb_avg_fragment_size_locks[
|
|
|
|
grp->bb_avg_fragment_size_order]);
|
|
|
|
list_del(&grp->bb_avg_fragment_size_node);
|
|
|
|
write_unlock(&sbi->s_mb_avg_fragment_size_locks[
|
|
|
|
grp->bb_avg_fragment_size_order]);
|
|
|
|
}
|
|
|
|
grp->bb_avg_fragment_size_order = new_order;
|
|
|
|
write_lock(&sbi->s_mb_avg_fragment_size_locks[
|
|
|
|
grp->bb_avg_fragment_size_order]);
|
|
|
|
list_add_tail(&grp->bb_avg_fragment_size_node,
|
|
|
|
&sbi->s_mb_avg_fragment_size[grp->bb_avg_fragment_size_order]);
|
|
|
|
write_unlock(&sbi->s_mb_avg_fragment_size_locks[
|
|
|
|
grp->bb_avg_fragment_size_order]);
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Choose next group by traversing largest_free_order lists. Updates *new_cr if
|
|
|
|
* cr level needs an update.
|
|
|
|
*/
|
2023-05-30 12:33:50 +00:00
|
|
|
static void ext4_mb_choose_next_group_p2_aligned(struct ext4_allocation_context *ac,
|
2024-01-05 09:20:55 +00:00
|
|
|
enum criteria *new_cr, ext4_group_t *group)
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
{
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(ac->ac_sb);
|
2023-08-01 14:31:57 +00:00
|
|
|
struct ext4_group_info *iter;
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
int i;
|
|
|
|
|
|
|
|
if (ac->ac_status == AC_STATUS_FOUND)
|
|
|
|
return;
|
|
|
|
|
2023-05-30 12:33:50 +00:00
|
|
|
if (unlikely(sbi->s_mb_stats && ac->ac_flags & EXT4_MB_CR_POWER2_ALIGNED_OPTIMIZED))
|
|
|
|
atomic_inc(&sbi->s_bal_p2_aligned_bad_suggestions);
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
|
|
|
|
for (i = ac->ac_2order; i < MB_NUM_ORDERS(ac->ac_sb); i++) {
|
|
|
|
if (list_empty(&sbi->s_mb_largest_free_orders[i]))
|
|
|
|
continue;
|
|
|
|
read_lock(&sbi->s_mb_largest_free_orders_locks[i]);
|
|
|
|
if (list_empty(&sbi->s_mb_largest_free_orders[i])) {
|
|
|
|
read_unlock(&sbi->s_mb_largest_free_orders_locks[i]);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
list_for_each_entry(iter, &sbi->s_mb_largest_free_orders[i],
|
|
|
|
bb_largest_free_order_node) {
|
|
|
|
if (sbi->s_mb_stats)
|
2023-05-30 12:33:50 +00:00
|
|
|
atomic64_inc(&sbi->s_bal_cX_groups_considered[CR_POWER2_ALIGNED]);
|
|
|
|
if (likely(ext4_mb_good_group(ac, iter->bb_group, CR_POWER2_ALIGNED))) {
|
2023-08-01 14:31:57 +00:00
|
|
|
*group = iter->bb_group;
|
|
|
|
ac->ac_flags |= EXT4_MB_CR_POWER2_ALIGNED_OPTIMIZED;
|
|
|
|
read_unlock(&sbi->s_mb_largest_free_orders_locks[i]);
|
|
|
|
return;
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
read_unlock(&sbi->s_mb_largest_free_orders_locks[i]);
|
|
|
|
}
|
|
|
|
|
2023-08-01 14:31:57 +00:00
|
|
|
/* Increment cr and search again if no group is found */
|
|
|
|
*new_cr = CR_GOAL_LEN_FAST;
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
}
|
|
|
|
|
2023-05-30 12:33:48 +00:00
|
|
|
/*
|
|
|
|
* Find a suitable group of given order from the average fragments list.
|
|
|
|
*/
|
|
|
|
static struct ext4_group_info *
|
|
|
|
ext4_mb_find_good_group_avg_frag_lists(struct ext4_allocation_context *ac, int order)
|
|
|
|
{
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(ac->ac_sb);
|
|
|
|
struct list_head *frag_list = &sbi->s_mb_avg_fragment_size[order];
|
|
|
|
rwlock_t *frag_list_lock = &sbi->s_mb_avg_fragment_size_locks[order];
|
|
|
|
struct ext4_group_info *grp = NULL, *iter;
|
|
|
|
enum criteria cr = ac->ac_criteria;
|
|
|
|
|
|
|
|
if (list_empty(frag_list))
|
|
|
|
return NULL;
|
|
|
|
read_lock(frag_list_lock);
|
|
|
|
if (list_empty(frag_list)) {
|
|
|
|
read_unlock(frag_list_lock);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
list_for_each_entry(iter, frag_list, bb_avg_fragment_size_node) {
|
|
|
|
if (sbi->s_mb_stats)
|
|
|
|
atomic64_inc(&sbi->s_bal_cX_groups_considered[cr]);
|
|
|
|
if (likely(ext4_mb_good_group(ac, iter->bb_group, cr))) {
|
|
|
|
grp = iter;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
read_unlock(frag_list_lock);
|
|
|
|
return grp;
|
|
|
|
}
|
|
|
|
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
/*
|
2022-09-08 09:21:28 +00:00
|
|
|
* Choose next group by traversing average fragment size list of suitable
|
|
|
|
* order. Updates *new_cr if cr level needs an update.
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
*/
|
2023-05-30 12:33:50 +00:00
|
|
|
static void ext4_mb_choose_next_group_goal_fast(struct ext4_allocation_context *ac,
|
2024-01-05 09:20:55 +00:00
|
|
|
enum criteria *new_cr, ext4_group_t *group)
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
{
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(ac->ac_sb);
|
2023-05-30 12:33:48 +00:00
|
|
|
struct ext4_group_info *grp = NULL;
|
2022-09-08 09:21:28 +00:00
|
|
|
int i;
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
|
2023-05-30 12:33:50 +00:00
|
|
|
if (unlikely(ac->ac_flags & EXT4_MB_CR_GOAL_LEN_FAST_OPTIMIZED)) {
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
if (sbi->s_mb_stats)
|
2023-05-30 12:33:50 +00:00
|
|
|
atomic_inc(&sbi->s_bal_goal_fast_bad_suggestions);
|
2022-09-08 09:21:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
for (i = mb_avg_fragment_size_order(ac->ac_sb, ac->ac_g_ex.fe_len);
|
|
|
|
i < MB_NUM_ORDERS(ac->ac_sb); i++) {
|
2023-05-30 12:33:48 +00:00
|
|
|
grp = ext4_mb_find_good_group_avg_frag_lists(ac, i);
|
2023-08-01 14:32:02 +00:00
|
|
|
if (grp) {
|
|
|
|
*group = grp->bb_group;
|
|
|
|
ac->ac_flags |= EXT4_MB_CR_GOAL_LEN_FAST_OPTIMIZED;
|
|
|
|
return;
|
|
|
|
}
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
}
|
|
|
|
|
2023-07-16 14:03:34 +00:00
|
|
|
/*
|
|
|
|
* CR_BEST_AVAIL_LEN works based on the concept that we have
|
|
|
|
* a larger normalized goal len request which can be trimmed to
|
|
|
|
* a smaller goal len such that it can still satisfy original
|
|
|
|
* request len. However, allocation request for non-regular
|
|
|
|
* files never gets normalized.
|
|
|
|
* See function ext4_mb_normalize_request() (EXT4_MB_HINT_DATA).
|
|
|
|
*/
|
|
|
|
if (ac->ac_flags & EXT4_MB_HINT_DATA)
|
|
|
|
*new_cr = CR_BEST_AVAIL_LEN;
|
|
|
|
else
|
|
|
|
*new_cr = CR_GOAL_LEN_SLOW;
|
2023-05-30 12:33:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2023-05-30 12:33:50 +00:00
|
|
|
* We couldn't find a group in CR_GOAL_LEN_FAST so try to find the highest free fragment
|
2023-05-30 12:33:49 +00:00
|
|
|
* order we have and proactively trim the goal request length to that order to
|
|
|
|
* find a suitable group faster.
|
|
|
|
*
|
|
|
|
* This optimizes allocation speed at the cost of slightly reduced
|
|
|
|
* preallocations. However, we make sure that we don't trim the request too
|
2023-05-30 12:33:50 +00:00
|
|
|
* much and fall to CR_GOAL_LEN_SLOW in that case.
|
2023-05-30 12:33:49 +00:00
|
|
|
*/
|
2023-05-30 12:33:50 +00:00
|
|
|
static void ext4_mb_choose_next_group_best_avail(struct ext4_allocation_context *ac,
|
2024-01-05 09:20:55 +00:00
|
|
|
enum criteria *new_cr, ext4_group_t *group)
|
2023-05-30 12:33:49 +00:00
|
|
|
{
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(ac->ac_sb);
|
|
|
|
struct ext4_group_info *grp = NULL;
|
|
|
|
int i, order, min_order;
|
|
|
|
unsigned long num_stripe_clusters = 0;
|
|
|
|
|
2023-05-30 12:33:50 +00:00
|
|
|
if (unlikely(ac->ac_flags & EXT4_MB_CR_BEST_AVAIL_LEN_OPTIMIZED)) {
|
2023-05-30 12:33:49 +00:00
|
|
|
if (sbi->s_mb_stats)
|
2023-05-30 12:33:50 +00:00
|
|
|
atomic_inc(&sbi->s_bal_best_avail_bad_suggestions);
|
2023-05-30 12:33:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* mb_avg_fragment_size_order() returns order in a way that makes
|
|
|
|
* retrieving back the length using (1 << order) inaccurate. Hence, use
|
|
|
|
* fls() instead since we need to know the actual length while modifying
|
|
|
|
* goal length.
|
|
|
|
*/
|
2023-06-09 10:34:03 +00:00
|
|
|
order = fls(ac->ac_g_ex.fe_len) - 1;
|
2024-03-19 11:33:20 +00:00
|
|
|
if (WARN_ON_ONCE(order - 1 > MB_NUM_ORDERS(ac->ac_sb)))
|
|
|
|
order = MB_NUM_ORDERS(ac->ac_sb);
|
2023-05-30 12:33:50 +00:00
|
|
|
min_order = order - sbi->s_mb_best_avail_max_trim_order;
|
2023-05-30 12:33:49 +00:00
|
|
|
if (min_order < 0)
|
|
|
|
min_order = 0;
|
|
|
|
|
|
|
|
if (sbi->s_stripe > 0) {
|
|
|
|
/*
|
|
|
|
* We are assuming that stripe size is always a multiple of
|
|
|
|
* cluster ratio otherwise __ext4_fill_super exists early.
|
|
|
|
*/
|
|
|
|
num_stripe_clusters = EXT4_NUM_B2C(sbi, sbi->s_stripe);
|
|
|
|
if (1 << min_order < num_stripe_clusters)
|
2023-06-09 10:34:03 +00:00
|
|
|
/*
|
|
|
|
* We consider 1 order less because later we round
|
|
|
|
* up the goal len to num_stripe_clusters
|
|
|
|
*/
|
|
|
|
min_order = fls(num_stripe_clusters) - 1;
|
2023-05-30 12:33:49 +00:00
|
|
|
}
|
|
|
|
|
2023-06-09 10:34:03 +00:00
|
|
|
if (1 << min_order < ac->ac_o_ex.fe_len)
|
|
|
|
min_order = fls(ac->ac_o_ex.fe_len);
|
|
|
|
|
2023-05-30 12:33:49 +00:00
|
|
|
for (i = order; i >= min_order; i--) {
|
|
|
|
int frag_order;
|
|
|
|
/*
|
|
|
|
* Scale down goal len to make sure we find something
|
|
|
|
* in the free fragments list. Basically, reduce
|
|
|
|
* preallocations.
|
|
|
|
*/
|
|
|
|
ac->ac_g_ex.fe_len = 1 << i;
|
|
|
|
|
|
|
|
if (num_stripe_clusters > 0) {
|
|
|
|
/*
|
2023-06-08 14:39:35 +00:00
|
|
|
* Try to round up the adjusted goal length to
|
|
|
|
* stripe size (in cluster units) multiple for
|
|
|
|
* efficiency.
|
2023-05-30 12:33:49 +00:00
|
|
|
*/
|
|
|
|
ac->ac_g_ex.fe_len = roundup(ac->ac_g_ex.fe_len,
|
|
|
|
num_stripe_clusters);
|
|
|
|
}
|
|
|
|
|
|
|
|
frag_order = mb_avg_fragment_size_order(ac->ac_sb,
|
|
|
|
ac->ac_g_ex.fe_len);
|
|
|
|
|
|
|
|
grp = ext4_mb_find_good_group_avg_frag_lists(ac, frag_order);
|
2023-08-01 14:32:03 +00:00
|
|
|
if (grp) {
|
|
|
|
*group = grp->bb_group;
|
|
|
|
ac->ac_flags |= EXT4_MB_CR_BEST_AVAIL_LEN_OPTIMIZED;
|
|
|
|
return;
|
|
|
|
}
|
2023-05-30 12:33:49 +00:00
|
|
|
}
|
|
|
|
|
2023-08-01 14:32:03 +00:00
|
|
|
/* Reset goal length to original goal length before falling into CR_GOAL_LEN_SLOW */
|
|
|
|
ac->ac_g_ex.fe_len = ac->ac_orig_goal_len;
|
|
|
|
*new_cr = CR_GOAL_LEN_SLOW;
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline int should_optimize_scan(struct ext4_allocation_context *ac)
|
|
|
|
{
|
|
|
|
if (unlikely(!test_opt2(ac->ac_sb, MB_OPTIMIZE_SCAN)))
|
|
|
|
return 0;
|
2023-05-30 12:33:50 +00:00
|
|
|
if (ac->ac_criteria >= CR_GOAL_LEN_SLOW)
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
return 0;
|
2022-03-08 09:52:01 +00:00
|
|
|
if (!ext4_test_inode_flag(ac->ac_inode, EXT4_INODE_EXTENTS))
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
return 0;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2024-04-24 06:19:04 +00:00
|
|
|
* Return next linear group for allocation.
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
*/
|
2023-08-01 14:31:56 +00:00
|
|
|
static ext4_group_t
|
2024-04-24 06:19:04 +00:00
|
|
|
next_linear_group(ext4_group_t group, ext4_group_t ngroups)
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Artificially restricted ngroups for non-extent
|
|
|
|
* files makes group > ngroups possible on first loop.
|
|
|
|
*/
|
|
|
|
return group + 1 >= ngroups ? 0 : group + 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ext4_mb_choose_next_group: choose next group for allocation.
|
|
|
|
*
|
|
|
|
* @ac Allocation Context
|
|
|
|
* @new_cr This is an output parameter. If the there is no good group
|
|
|
|
* available at current CR level, this field is updated to indicate
|
|
|
|
* the new cr level that should be used.
|
|
|
|
* @group This is an input / output parameter. As an input it indicates the
|
|
|
|
* next group that the allocator intends to use for allocation. As
|
|
|
|
* output, this field indicates the next group that should be used as
|
|
|
|
* determined by the optimization functions.
|
|
|
|
* @ngroups Total number of groups
|
|
|
|
*/
|
|
|
|
static void ext4_mb_choose_next_group(struct ext4_allocation_context *ac,
|
2023-05-30 12:33:42 +00:00
|
|
|
enum criteria *new_cr, ext4_group_t *group, ext4_group_t ngroups)
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
{
|
|
|
|
*new_cr = ac->ac_criteria;
|
|
|
|
|
2024-04-24 06:19:04 +00:00
|
|
|
if (!should_optimize_scan(ac)) {
|
|
|
|
*group = next_linear_group(*group, ngroups);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Optimized scanning can return non adjacent groups which can cause
|
|
|
|
* seek overhead for rotational disks. So try few linear groups before
|
|
|
|
* trying optimized scan.
|
|
|
|
*/
|
|
|
|
if (ac->ac_groups_linear_remaining) {
|
|
|
|
*group = next_linear_group(*group, ngroups);
|
|
|
|
ac->ac_groups_linear_remaining--;
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
return;
|
2022-09-08 09:21:24 +00:00
|
|
|
}
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
|
2023-05-30 12:33:50 +00:00
|
|
|
if (*new_cr == CR_POWER2_ALIGNED) {
|
2024-01-05 09:20:55 +00:00
|
|
|
ext4_mb_choose_next_group_p2_aligned(ac, new_cr, group);
|
2023-05-30 12:33:50 +00:00
|
|
|
} else if (*new_cr == CR_GOAL_LEN_FAST) {
|
2024-01-05 09:20:55 +00:00
|
|
|
ext4_mb_choose_next_group_goal_fast(ac, new_cr, group);
|
2023-05-30 12:33:50 +00:00
|
|
|
} else if (*new_cr == CR_BEST_AVAIL_LEN) {
|
2024-01-05 09:20:55 +00:00
|
|
|
ext4_mb_choose_next_group_best_avail(ac, new_cr, group);
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
} else {
|
|
|
|
/*
|
2024-04-24 06:19:03 +00:00
|
|
|
* TODO: For CR_GOAL_LEN_SLOW, we can arrange groups in an
|
|
|
|
* rb tree sorted by bb_free. But until that happens, we should
|
|
|
|
* never come here.
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
*/
|
|
|
|
WARN_ON(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-05-16 19:00:00 +00:00
|
|
|
/*
|
|
|
|
* Cache the order of the largest free extent we have available in this block
|
|
|
|
* group.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
mb_set_largest_free_order(struct super_block *sb, struct ext4_group_info *grp)
|
|
|
|
{
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
2010-05-16 19:00:00 +00:00
|
|
|
int i;
|
|
|
|
|
2022-09-08 09:21:25 +00:00
|
|
|
for (i = MB_NUM_ORDERS(sb) - 1; i >= 0; i--)
|
|
|
|
if (grp->bb_counters[i] > 0)
|
|
|
|
break;
|
|
|
|
/* No need to move between order lists? */
|
|
|
|
if (!test_opt2(sb, MB_OPTIMIZE_SCAN) ||
|
|
|
|
i == grp->bb_largest_free_order) {
|
|
|
|
grp->bb_largest_free_order = i;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (grp->bb_largest_free_order >= 0) {
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
write_lock(&sbi->s_mb_largest_free_orders_locks[
|
|
|
|
grp->bb_largest_free_order]);
|
|
|
|
list_del_init(&grp->bb_largest_free_order_node);
|
|
|
|
write_unlock(&sbi->s_mb_largest_free_orders_locks[
|
|
|
|
grp->bb_largest_free_order]);
|
|
|
|
}
|
2022-09-08 09:21:25 +00:00
|
|
|
grp->bb_largest_free_order = i;
|
|
|
|
if (grp->bb_largest_free_order >= 0 && grp->bb_free) {
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
write_lock(&sbi->s_mb_largest_free_orders_locks[
|
|
|
|
grp->bb_largest_free_order]);
|
|
|
|
list_add_tail(&grp->bb_largest_free_order_node,
|
|
|
|
&sbi->s_mb_largest_free_orders[grp->bb_largest_free_order]);
|
|
|
|
write_unlock(&sbi->s_mb_largest_free_orders_locks[
|
|
|
|
grp->bb_largest_free_order]);
|
|
|
|
}
|
2010-05-16 19:00:00 +00:00
|
|
|
}
|
|
|
|
|
2009-07-06 02:17:31 +00:00
|
|
|
static noinline_for_stack
|
|
|
|
void ext4_mb_generate_buddy(struct super_block *sb,
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
void *buddy, void *bitmap, ext4_group_t group,
|
|
|
|
struct ext4_group_info *grp)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
2014-06-26 14:11:53 +00:00
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
2011-09-09 22:38:51 +00:00
|
|
|
ext4_grpblk_t max = EXT4_CLUSTERS_PER_GROUP(sb);
|
2009-08-26 02:36:45 +00:00
|
|
|
ext4_grpblk_t i = 0;
|
|
|
|
ext4_grpblk_t first;
|
|
|
|
ext4_grpblk_t len;
|
2008-01-29 05:19:52 +00:00
|
|
|
unsigned free = 0;
|
|
|
|
unsigned fragments = 0;
|
|
|
|
unsigned long long period = get_cycles();
|
|
|
|
|
|
|
|
/* initialize buddy from bitmap which is aggregation
|
|
|
|
* of on-disk bitmap and preallocations */
|
2008-02-23 06:38:34 +00:00
|
|
|
i = mb_find_next_zero_bit(bitmap, max, 0);
|
2008-01-29 05:19:52 +00:00
|
|
|
grp->bb_first_free = i;
|
|
|
|
while (i < max) {
|
|
|
|
fragments++;
|
|
|
|
first = i;
|
2008-02-23 06:38:34 +00:00
|
|
|
i = mb_find_next_bit(bitmap, max, i);
|
2008-01-29 05:19:52 +00:00
|
|
|
len = i - first;
|
|
|
|
free += len;
|
|
|
|
if (len > 1)
|
|
|
|
ext4_mb_mark_free_simple(sb, buddy, first, len, grp);
|
|
|
|
else
|
|
|
|
grp->bb_counters[0]++;
|
|
|
|
if (i < max)
|
2008-02-23 06:38:34 +00:00
|
|
|
i = mb_find_next_zero_bit(bitmap, max, i);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
grp->bb_fragments = fragments;
|
|
|
|
|
|
|
|
if (free != grp->bb_free) {
|
2010-06-29 16:54:28 +00:00
|
|
|
ext4_grp_locked_error(sb, group, 0, 0,
|
2014-07-05 23:15:50 +00:00
|
|
|
"block bitmap and bg descriptor "
|
|
|
|
"inconsistent: %u vs %u free clusters",
|
2010-06-29 16:54:28 +00:00
|
|
|
free, grp->bb_free);
|
2008-02-15 18:48:21 +00:00
|
|
|
/*
|
ext4: mark block group as corrupt on block bitmap error
When we notice a block-bitmap corruption (because of device failure or
something else), we should mark this group as corrupt and prevent
further block allocations/deallocations from it. Currently, we end up
generating one error message for every block in the bitmap. This
potentially could make the system unstable as noticed in some
bugs. With this patch, the error will be printed only the first time
and mark the entire block group as corrupted. This prevents future
access allocations/deallocations from it.
Also tested by corrupting the block
bitmap and forcefully introducing the mb_free_blocks error:
(1) create a largefile (2Gb)
$ dd if=/dev/zero of=largefile oflag=direct bs=10485760 count=200
(2) umount filesystem. use dumpe2fs to see which block-bitmaps
are in use by largefile and note their block numbers
(3) use dd to zero-out the used block bitmaps
$ dd if=/dev/zero of=/dev/hdc4 bs=4096 seek=14 count=8 oflag=direct
(4) mount the FS and delete the largefile.
(5) recreate the largefile. verify that the new largefile does not
get any blocks from the groups marked as bad.
Without the patch, we will see mb_free_blocks error for each bit in
each zero'ed out bitmap at (4). With the patch, we only see the error
once per blockgroup:
[ 309.706803] EXT4-fs error (device sdb4): ext4_mb_generate_buddy:735: group 15: 32768 clusters in bitmap, 0 in gd. blk grp corrupted.
[ 309.720824] EXT4-fs error (device sdb4): ext4_mb_generate_buddy:735: group 14: 32768 clusters in bitmap, 0 in gd. blk grp corrupted.
[ 309.732858] EXT4-fs error (device sdb4) in ext4_free_blocks:4802: IO failure
[ 309.748321] EXT4-fs error (device sdb4): ext4_mb_generate_buddy:735: group 13: 32768 clusters in bitmap, 0 in gd. blk grp corrupted.
[ 309.760331] EXT4-fs error (device sdb4) in ext4_free_blocks:4802: IO failure
[ 309.769695] EXT4-fs error (device sdb4): ext4_mb_generate_buddy:735: group 12: 32768 clusters in bitmap, 0 in gd. blk grp corrupted.
[ 309.781721] EXT4-fs error (device sdb4) in ext4_free_blocks:4802: IO failure
[ 309.798166] EXT4-fs error (device sdb4): ext4_mb_generate_buddy:735: group 11: 32768 clusters in bitmap, 0 in gd. blk grp corrupted.
[ 309.810184] EXT4-fs error (device sdb4) in ext4_free_blocks:4802: IO failure
[ 309.819532] EXT4-fs error (device sdb4): ext4_mb_generate_buddy:735: group 10: 32768 clusters in bitmap, 0 in gd. blk grp corrupted.
Google-Bug-Id: 7258357
[darrick.wong@oracle.com]
Further modifications (by Darrick) to make more obvious that this corruption
bit applies to blocks only. Set the corruption flag if the block group bitmap
verification fails.
Original-author: Aditya Kali <adityakali@google.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2013-08-28 21:35:51 +00:00
|
|
|
* If we intend to continue, we consider group descriptor
|
2008-02-15 18:48:21 +00:00
|
|
|
* corrupt and update bb_free using bitmap value
|
|
|
|
*/
|
2008-01-29 05:19:52 +00:00
|
|
|
grp->bb_free = free;
|
2018-05-12 15:39:40 +00:00
|
|
|
ext4_mark_group_bitmap_corrupted(sb, group,
|
|
|
|
EXT4_GROUP_INFO_BBITMAP_CORRUPT);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2010-05-16 19:00:00 +00:00
|
|
|
mb_set_largest_free_order(sb, grp);
|
2022-09-08 09:21:28 +00:00
|
|
|
mb_update_avg_fragment_size(sb, grp);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
clear_bit(EXT4_GROUP_INFO_NEED_INIT_BIT, &(grp->bb_state));
|
|
|
|
|
|
|
|
period = get_cycles() - period;
|
2021-04-01 17:21:23 +00:00
|
|
|
atomic_inc(&sbi->s_mb_buddies_generated);
|
|
|
|
atomic64_add(period, &sbi->s_mb_generation_time);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
2024-01-04 14:20:35 +00:00
|
|
|
static void mb_regenerate_buddy(struct ext4_buddy *e4b)
|
|
|
|
{
|
|
|
|
int count;
|
|
|
|
int order = 1;
|
|
|
|
void *buddy;
|
|
|
|
|
|
|
|
while ((buddy = mb_find_buddy(e4b, order++, &count)))
|
|
|
|
mb_set_bits(buddy, 0, count);
|
|
|
|
|
|
|
|
e4b->bd_info->bb_fragments = 0;
|
|
|
|
memset(e4b->bd_info->bb_counters, 0,
|
|
|
|
sizeof(*e4b->bd_info->bb_counters) *
|
|
|
|
(e4b->bd_sb->s_blocksize_bits + 2));
|
|
|
|
|
|
|
|
ext4_mb_generate_buddy(e4b->bd_sb, e4b->bd_buddy,
|
|
|
|
e4b->bd_bitmap, e4b->bd_group, e4b->bd_info);
|
|
|
|
}
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
/* The buddy information is attached the buddy cache inode
|
|
|
|
* for convenience. The information regarding each group
|
|
|
|
* is loaded via ext4_mb_load_buddy. The information involve
|
|
|
|
* block bitmap and buddy information. The information are
|
|
|
|
* stored in the inode as
|
|
|
|
*
|
|
|
|
* { page }
|
2008-11-25 20:11:52 +00:00
|
|
|
* [ group 0 bitmap][ group 0 buddy] [group 1][ group 1]...
|
2008-01-29 05:19:52 +00:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* one block each for bitmap and buddy information.
|
|
|
|
* So for each group we take up 2 blocks. A page can
|
2016-04-01 12:29:48 +00:00
|
|
|
* contain blocks_per_page (PAGE_SIZE / blocksize) blocks.
|
2008-01-29 05:19:52 +00:00
|
|
|
* So it can have information regarding groups_per_page which
|
|
|
|
* is blocks_per_page/2
|
2010-05-16 19:00:00 +00:00
|
|
|
*
|
|
|
|
* Locking note: This routine takes the block group lock of all groups
|
|
|
|
* for this page; do not hold this lock when calling this routine!
|
2008-01-29 05:19:52 +00:00
|
|
|
*/
|
|
|
|
|
2024-04-16 17:28:56 +00:00
|
|
|
static int ext4_mb_init_cache(struct folio *folio, char *incore, gfp_t gfp)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
2009-05-01 12:50:38 +00:00
|
|
|
ext4_group_t ngroups;
|
2023-07-07 10:55:16 +00:00
|
|
|
unsigned int blocksize;
|
2008-01-29 05:19:52 +00:00
|
|
|
int blocks_per_page;
|
|
|
|
int groups_per_page;
|
|
|
|
int err = 0;
|
|
|
|
int i;
|
2012-02-20 22:52:46 +00:00
|
|
|
ext4_group_t first_group, group;
|
2008-01-29 05:19:52 +00:00
|
|
|
int first_block;
|
|
|
|
struct super_block *sb;
|
|
|
|
struct buffer_head *bhs;
|
2012-04-29 22:35:10 +00:00
|
|
|
struct buffer_head **bh = NULL;
|
2008-01-29 05:19:52 +00:00
|
|
|
struct inode *inode;
|
|
|
|
char *data;
|
|
|
|
char *bitmap;
|
2011-05-10 01:49:42 +00:00
|
|
|
struct ext4_group_info *grinfo;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2024-04-16 17:28:56 +00:00
|
|
|
inode = folio->mapping->host;
|
2008-01-29 05:19:52 +00:00
|
|
|
sb = inode->i_sb;
|
2009-05-01 12:50:38 +00:00
|
|
|
ngroups = ext4_get_groups_count(sb);
|
2017-02-27 22:28:32 +00:00
|
|
|
blocksize = i_blocksize(inode);
|
mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros
PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time
ago with promise that one day it will be possible to implement page
cache with bigger chunks than PAGE_SIZE.
This promise never materialized. And unlikely will.
We have many places where PAGE_CACHE_SIZE assumed to be equal to
PAGE_SIZE. And it's constant source of confusion on whether
PAGE_CACHE_* or PAGE_* constant should be used in a particular case,
especially on the border between fs and mm.
Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
breakage to be doable.
Let's stop pretending that pages in page cache are special. They are
not.
The changes are pretty straight-forward:
- <foo> << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
- <foo> >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
- PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};
- page_cache_get() -> get_page();
- page_cache_release() -> put_page();
This patch contains automated changes generated with coccinelle using
script below. For some reason, coccinelle doesn't patch header files.
I've called spatch for them manually.
The only adjustment after coccinelle is revert of changes to
PAGE_CAHCE_ALIGN definition: we are going to drop it later.
There are few places in the code where coccinelle didn't reach. I'll
fix them manually in a separate patch. Comments and documentation also
will be addressed with the separate patch.
virtual patch
@@
expression E;
@@
- E << (PAGE_CACHE_SHIFT - PAGE_SHIFT)
+ E
@@
expression E;
@@
- E >> (PAGE_CACHE_SHIFT - PAGE_SHIFT)
+ E
@@
@@
- PAGE_CACHE_SHIFT
+ PAGE_SHIFT
@@
@@
- PAGE_CACHE_SIZE
+ PAGE_SIZE
@@
@@
- PAGE_CACHE_MASK
+ PAGE_MASK
@@
expression E;
@@
- PAGE_CACHE_ALIGN(E)
+ PAGE_ALIGN(E)
@@
expression E;
@@
- page_cache_get(E)
+ get_page(E)
@@
expression E;
@@
- page_cache_release(E)
+ put_page(E)
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-01 12:29:47 +00:00
|
|
|
blocks_per_page = PAGE_SIZE / blocksize;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2024-04-16 17:28:56 +00:00
|
|
|
mb_debug(sb, "init folio %lu\n", folio->index);
|
2020-05-10 06:24:54 +00:00
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
groups_per_page = blocks_per_page >> 1;
|
|
|
|
if (groups_per_page == 0)
|
|
|
|
groups_per_page = 1;
|
|
|
|
|
|
|
|
/* allocate buffer_heads to read bitmaps */
|
|
|
|
if (groups_per_page > 1) {
|
|
|
|
i = sizeof(struct buffer_head *) * groups_per_page;
|
2016-03-13 21:29:06 +00:00
|
|
|
bh = kzalloc(i, gfp);
|
2023-03-03 17:21:09 +00:00
|
|
|
if (bh == NULL)
|
|
|
|
return -ENOMEM;
|
2008-01-29 05:19:52 +00:00
|
|
|
} else
|
|
|
|
bh = &bhs;
|
|
|
|
|
2024-04-16 17:28:56 +00:00
|
|
|
first_group = folio->index * blocks_per_page / 2;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2024-04-16 17:28:56 +00:00
|
|
|
/* read all groups the folio covers into the cache */
|
2012-02-20 22:52:46 +00:00
|
|
|
for (i = 0, group = first_group; i < groups_per_page; i++, group++) {
|
|
|
|
if (group >= ngroups)
|
2008-01-29 05:19:52 +00:00
|
|
|
break;
|
|
|
|
|
2012-02-20 22:52:46 +00:00
|
|
|
grinfo = ext4_get_group_info(sb, group);
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
if (!grinfo)
|
|
|
|
continue;
|
2011-05-10 01:49:42 +00:00
|
|
|
/*
|
|
|
|
* If page is uptodate then we came here after online resize
|
|
|
|
* which added some new uninitialized group info structs, so
|
2024-04-16 17:28:56 +00:00
|
|
|
* we must skip all initialized uptodate buddies on the folio,
|
2011-05-10 01:49:42 +00:00
|
|
|
* which may be currently in use by an allocating task.
|
|
|
|
*/
|
2024-04-16 17:28:56 +00:00
|
|
|
if (folio_test_uptodate(folio) &&
|
|
|
|
!EXT4_MB_GRP_NEED_INIT(grinfo)) {
|
2011-05-10 01:49:42 +00:00
|
|
|
bh[i] = NULL;
|
|
|
|
continue;
|
|
|
|
}
|
2020-04-21 07:54:07 +00:00
|
|
|
bh[i] = ext4_read_block_bitmap_nowait(sb, group, false);
|
2015-10-18 01:33:24 +00:00
|
|
|
if (IS_ERR(bh[i])) {
|
|
|
|
err = PTR_ERR(bh[i]);
|
|
|
|
bh[i] = NULL;
|
2008-01-29 05:19:52 +00:00
|
|
|
goto out;
|
2009-01-06 02:49:55 +00:00
|
|
|
}
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "read bitmap for group %u\n", group);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* wait for I/O completion */
|
2012-02-20 22:52:46 +00:00
|
|
|
for (i = 0, group = first_group; i < groups_per_page; i++, group++) {
|
2015-10-18 01:33:24 +00:00
|
|
|
int err2;
|
|
|
|
|
|
|
|
if (!bh[i])
|
|
|
|
continue;
|
|
|
|
err2 = ext4_wait_block_bitmap(sb, group, bh[i]);
|
|
|
|
if (!err)
|
|
|
|
err = err2;
|
2012-02-20 22:52:46 +00:00
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2024-04-16 17:28:56 +00:00
|
|
|
first_block = folio->index * blocks_per_page;
|
2008-01-29 05:19:52 +00:00
|
|
|
for (i = 0; i < blocks_per_page; i++) {
|
|
|
|
group = (first_block + i) >> 1;
|
2009-05-01 12:50:38 +00:00
|
|
|
if (group >= ngroups)
|
2008-01-29 05:19:52 +00:00
|
|
|
break;
|
|
|
|
|
2011-05-10 01:49:42 +00:00
|
|
|
if (!bh[group - first_group])
|
|
|
|
/* skip initialized uptodate buddy */
|
|
|
|
continue;
|
|
|
|
|
2015-06-08 15:38:37 +00:00
|
|
|
if (!buffer_verified(bh[group - first_group]))
|
|
|
|
/* Skip faulty bitmaps */
|
|
|
|
continue;
|
|
|
|
err = 0;
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
/*
|
|
|
|
* data carry information regarding this
|
|
|
|
* particular group in the format specified
|
|
|
|
* above
|
|
|
|
*
|
|
|
|
*/
|
2024-04-16 17:28:56 +00:00
|
|
|
data = folio_address(folio) + (i * blocksize);
|
2008-01-29 05:19:52 +00:00
|
|
|
bitmap = bh[group - first_group]->b_data;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We place the buddy block and bitmap block
|
|
|
|
* close together
|
|
|
|
*/
|
2023-08-24 15:56:31 +00:00
|
|
|
grinfo = ext4_get_group_info(sb, group);
|
|
|
|
if (!grinfo) {
|
|
|
|
err = -EFSCORRUPTED;
|
|
|
|
goto out;
|
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
if ((first_block + i) & 1) {
|
|
|
|
/* this is block of buddy */
|
|
|
|
BUG_ON(incore == NULL);
|
2024-04-16 17:28:56 +00:00
|
|
|
mb_debug(sb, "put buddy for group %u in folio %lu/%x\n",
|
|
|
|
group, folio->index, i * blocksize);
|
2010-05-17 07:00:00 +00:00
|
|
|
trace_ext4_mb_buddy_bitmap_load(sb, group);
|
2008-01-29 05:19:52 +00:00
|
|
|
grinfo->bb_fragments = 0;
|
|
|
|
memset(grinfo->bb_counters, 0,
|
2009-08-26 02:36:25 +00:00
|
|
|
sizeof(*grinfo->bb_counters) *
|
2021-04-01 17:21:26 +00:00
|
|
|
(MB_NUM_ORDERS(sb)));
|
2008-01-29 05:19:52 +00:00
|
|
|
/*
|
|
|
|
* incore got set to the group block bitmap below
|
|
|
|
*/
|
2009-01-06 02:36:55 +00:00
|
|
|
ext4_lock_group(sb, group);
|
2011-05-10 01:49:42 +00:00
|
|
|
/* init the buddy */
|
|
|
|
memset(data, 0xff, blocksize);
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
ext4_mb_generate_buddy(sb, data, incore, group, grinfo);
|
2009-01-06 02:36:55 +00:00
|
|
|
ext4_unlock_group(sb, group);
|
2008-01-29 05:19:52 +00:00
|
|
|
incore = NULL;
|
|
|
|
} else {
|
|
|
|
/* this is block of bitmap */
|
|
|
|
BUG_ON(incore != NULL);
|
2024-04-16 17:28:56 +00:00
|
|
|
mb_debug(sb, "put bitmap for group %u in folio %lu/%x\n",
|
|
|
|
group, folio->index, i * blocksize);
|
2010-05-17 07:00:00 +00:00
|
|
|
trace_ext4_mb_bitmap_load(sb, group);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
/* see comments in ext4_mb_put_pa() */
|
|
|
|
ext4_lock_group(sb, group);
|
|
|
|
memcpy(data, bitmap, blocksize);
|
|
|
|
|
|
|
|
/* mark all preallocated blks used in in-core bitmap */
|
|
|
|
ext4_mb_generate_from_pa(sb, data, group);
|
2023-08-24 15:56:31 +00:00
|
|
|
WARN_ON_ONCE(!RB_EMPTY_ROOT(&grinfo->bb_free_root));
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_unlock_group(sb, group);
|
|
|
|
|
|
|
|
/* set incore so that the buddy information can be
|
|
|
|
* generated using this
|
|
|
|
*/
|
|
|
|
incore = data;
|
|
|
|
}
|
|
|
|
}
|
2024-04-16 17:28:56 +00:00
|
|
|
folio_mark_uptodate(folio);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
out:
|
|
|
|
if (bh) {
|
2011-05-10 01:49:42 +00:00
|
|
|
for (i = 0; i < groups_per_page; i++)
|
2008-01-29 05:19:52 +00:00
|
|
|
brelse(bh[i]);
|
|
|
|
if (bh != &bhs)
|
|
|
|
kfree(bh);
|
|
|
|
}
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2010-10-28 01:30:15 +00:00
|
|
|
/*
|
2011-05-10 01:48:13 +00:00
|
|
|
* Lock the buddy and bitmap pages. This make sure other parallel init_group
|
|
|
|
* on the same buddy page doesn't happen whild holding the buddy page lock.
|
|
|
|
* Return locked buddy and bitmap pages on e4b struct. If buddy and bitmap
|
2024-04-16 17:28:55 +00:00
|
|
|
* are on the same page e4b->bd_buddy_folio is NULL and return value is 0.
|
2010-10-28 01:30:15 +00:00
|
|
|
*/
|
2011-05-10 01:48:13 +00:00
|
|
|
static int ext4_mb_get_buddy_page_lock(struct super_block *sb,
|
2016-03-13 21:29:06 +00:00
|
|
|
ext4_group_t group, struct ext4_buddy *e4b, gfp_t gfp)
|
2010-10-28 01:30:15 +00:00
|
|
|
{
|
2011-05-10 01:48:13 +00:00
|
|
|
struct inode *inode = EXT4_SB(sb)->s_buddy_cache;
|
|
|
|
int block, pnum, poff;
|
2010-10-28 01:30:15 +00:00
|
|
|
int blocks_per_page;
|
2024-04-16 17:28:54 +00:00
|
|
|
struct folio *folio;
|
2011-05-10 01:48:13 +00:00
|
|
|
|
2024-04-16 17:28:55 +00:00
|
|
|
e4b->bd_buddy_folio = NULL;
|
2024-04-16 17:28:54 +00:00
|
|
|
e4b->bd_bitmap_folio = NULL;
|
2010-10-28 01:30:15 +00:00
|
|
|
|
mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros
PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time
ago with promise that one day it will be possible to implement page
cache with bigger chunks than PAGE_SIZE.
This promise never materialized. And unlikely will.
We have many places where PAGE_CACHE_SIZE assumed to be equal to
PAGE_SIZE. And it's constant source of confusion on whether
PAGE_CACHE_* or PAGE_* constant should be used in a particular case,
especially on the border between fs and mm.
Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
breakage to be doable.
Let's stop pretending that pages in page cache are special. They are
not.
The changes are pretty straight-forward:
- <foo> << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
- <foo> >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
- PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};
- page_cache_get() -> get_page();
- page_cache_release() -> put_page();
This patch contains automated changes generated with coccinelle using
script below. For some reason, coccinelle doesn't patch header files.
I've called spatch for them manually.
The only adjustment after coccinelle is revert of changes to
PAGE_CAHCE_ALIGN definition: we are going to drop it later.
There are few places in the code where coccinelle didn't reach. I'll
fix them manually in a separate patch. Comments and documentation also
will be addressed with the separate patch.
virtual patch
@@
expression E;
@@
- E << (PAGE_CACHE_SHIFT - PAGE_SHIFT)
+ E
@@
expression E;
@@
- E >> (PAGE_CACHE_SHIFT - PAGE_SHIFT)
+ E
@@
@@
- PAGE_CACHE_SHIFT
+ PAGE_SHIFT
@@
@@
- PAGE_CACHE_SIZE
+ PAGE_SIZE
@@
@@
- PAGE_CACHE_MASK
+ PAGE_MASK
@@
expression E;
@@
- PAGE_CACHE_ALIGN(E)
+ PAGE_ALIGN(E)
@@
expression E;
@@
- page_cache_get(E)
+ get_page(E)
@@
expression E;
@@
- page_cache_release(E)
+ put_page(E)
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-01 12:29:47 +00:00
|
|
|
blocks_per_page = PAGE_SIZE / sb->s_blocksize;
|
2010-10-28 01:30:15 +00:00
|
|
|
/*
|
|
|
|
* the buddy cache inode stores the block bitmap
|
|
|
|
* and buddy information in consecutive blocks.
|
|
|
|
* So for each group we need two blocks.
|
|
|
|
*/
|
|
|
|
block = group * 2;
|
|
|
|
pnum = block / blocks_per_page;
|
2011-05-10 01:48:13 +00:00
|
|
|
poff = block % blocks_per_page;
|
2024-04-16 17:28:54 +00:00
|
|
|
folio = __filemap_get_folio(inode->i_mapping, pnum,
|
|
|
|
FGP_LOCK | FGP_ACCESSED | FGP_CREAT, gfp);
|
|
|
|
if (IS_ERR(folio))
|
|
|
|
return PTR_ERR(folio);
|
|
|
|
BUG_ON(folio->mapping != inode->i_mapping);
|
|
|
|
e4b->bd_bitmap_folio = folio;
|
|
|
|
e4b->bd_bitmap = folio_address(folio) + (poff * sb->s_blocksize);
|
2011-05-10 01:48:13 +00:00
|
|
|
|
|
|
|
if (blocks_per_page >= 2) {
|
|
|
|
/* buddy and bitmap are on the same page */
|
|
|
|
return 0;
|
2010-10-28 01:30:15 +00:00
|
|
|
}
|
2011-05-10 01:48:13 +00:00
|
|
|
|
2023-10-24 03:52:15 +00:00
|
|
|
/* blocks_per_page == 1, hence we need another page for the buddy */
|
2024-04-16 17:28:55 +00:00
|
|
|
folio = __filemap_get_folio(inode->i_mapping, block + 1,
|
|
|
|
FGP_LOCK | FGP_ACCESSED | FGP_CREAT, gfp);
|
|
|
|
if (IS_ERR(folio))
|
|
|
|
return PTR_ERR(folio);
|
|
|
|
BUG_ON(folio->mapping != inode->i_mapping);
|
|
|
|
e4b->bd_buddy_folio = folio;
|
2011-05-10 01:48:13 +00:00
|
|
|
return 0;
|
2010-10-28 01:30:15 +00:00
|
|
|
}
|
|
|
|
|
2011-05-10 01:48:13 +00:00
|
|
|
static void ext4_mb_put_buddy_page_lock(struct ext4_buddy *e4b)
|
2010-10-28 01:30:15 +00:00
|
|
|
{
|
2024-04-16 17:28:54 +00:00
|
|
|
if (e4b->bd_bitmap_folio) {
|
|
|
|
folio_unlock(e4b->bd_bitmap_folio);
|
|
|
|
folio_put(e4b->bd_bitmap_folio);
|
2011-05-10 01:48:13 +00:00
|
|
|
}
|
2024-04-16 17:28:55 +00:00
|
|
|
if (e4b->bd_buddy_folio) {
|
|
|
|
folio_unlock(e4b->bd_buddy_folio);
|
|
|
|
folio_put(e4b->bd_buddy_folio);
|
2010-10-28 01:30:15 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-05-16 19:00:00 +00:00
|
|
|
/*
|
|
|
|
* Locking note: This routine calls ext4_mb_init_cache(), which takes the
|
|
|
|
* block group lock of all groups for this page; do not hold the BG lock when
|
|
|
|
* calling this routine!
|
|
|
|
*/
|
2009-09-10 03:47:46 +00:00
|
|
|
static noinline_for_stack
|
2016-03-13 21:29:06 +00:00
|
|
|
int ext4_mb_init_group(struct super_block *sb, ext4_group_t group, gfp_t gfp)
|
2009-09-10 03:47:46 +00:00
|
|
|
{
|
|
|
|
|
|
|
|
struct ext4_group_info *this_grp;
|
2011-05-10 01:48:13 +00:00
|
|
|
struct ext4_buddy e4b;
|
2024-04-16 17:28:54 +00:00
|
|
|
struct folio *folio;
|
2011-05-10 01:48:13 +00:00
|
|
|
int ret = 0;
|
2009-09-10 03:47:46 +00:00
|
|
|
|
2013-04-04 02:00:52 +00:00
|
|
|
might_sleep();
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "init group %u\n", group);
|
2009-09-10 03:47:46 +00:00
|
|
|
this_grp = ext4_get_group_info(sb, group);
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
if (!this_grp)
|
|
|
|
return -EFSCORRUPTED;
|
|
|
|
|
2009-09-10 03:47:46 +00:00
|
|
|
/*
|
2009-09-10 03:50:17 +00:00
|
|
|
* This ensures that we don't reinit the buddy cache
|
|
|
|
* page which map to the group from which we are already
|
|
|
|
* allocating. If we are looking at the buddy cache we would
|
|
|
|
* have taken a reference using ext4_mb_load_buddy and that
|
2011-05-10 01:48:13 +00:00
|
|
|
* would have pinned buddy page to page cache.
|
2014-06-04 23:10:31 +00:00
|
|
|
* The call to ext4_mb_get_buddy_page_lock will mark the
|
|
|
|
* page accessed.
|
2009-09-10 03:47:46 +00:00
|
|
|
*/
|
2016-03-13 21:29:06 +00:00
|
|
|
ret = ext4_mb_get_buddy_page_lock(sb, group, &e4b, gfp);
|
2011-05-10 01:48:13 +00:00
|
|
|
if (ret || !EXT4_MB_GRP_NEED_INIT(this_grp)) {
|
2009-09-10 03:47:46 +00:00
|
|
|
/*
|
|
|
|
* somebody initialized the group
|
|
|
|
* return without doing anything
|
|
|
|
*/
|
|
|
|
goto err;
|
|
|
|
}
|
2011-05-10 01:48:13 +00:00
|
|
|
|
2024-04-16 17:28:54 +00:00
|
|
|
folio = e4b.bd_bitmap_folio;
|
2024-04-16 17:28:56 +00:00
|
|
|
ret = ext4_mb_init_cache(folio, NULL, gfp);
|
2011-05-10 01:48:13 +00:00
|
|
|
if (ret)
|
|
|
|
goto err;
|
2024-04-16 17:28:54 +00:00
|
|
|
if (!folio_test_uptodate(folio)) {
|
2009-09-10 03:47:46 +00:00
|
|
|
ret = -EIO;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
2024-04-16 17:28:55 +00:00
|
|
|
if (e4b.bd_buddy_folio == NULL) {
|
2009-09-10 03:47:46 +00:00
|
|
|
/*
|
|
|
|
* If both the bitmap and buddy are in
|
|
|
|
* the same page we don't need to force
|
|
|
|
* init the buddy
|
|
|
|
*/
|
2011-05-10 01:48:13 +00:00
|
|
|
ret = 0;
|
|
|
|
goto err;
|
2009-09-10 03:47:46 +00:00
|
|
|
}
|
2011-05-10 01:48:13 +00:00
|
|
|
/* init buddy cache */
|
2024-04-16 17:28:55 +00:00
|
|
|
folio = e4b.bd_buddy_folio;
|
2024-04-16 17:28:56 +00:00
|
|
|
ret = ext4_mb_init_cache(folio, e4b.bd_bitmap, gfp);
|
2011-05-10 01:48:13 +00:00
|
|
|
if (ret)
|
|
|
|
goto err;
|
2024-04-16 17:28:55 +00:00
|
|
|
if (!folio_test_uptodate(folio)) {
|
2009-09-10 03:47:46 +00:00
|
|
|
ret = -EIO;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
err:
|
2011-05-10 01:48:13 +00:00
|
|
|
ext4_mb_put_buddy_page_lock(&e4b);
|
2009-09-10 03:47:46 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2010-05-16 19:00:00 +00:00
|
|
|
/*
|
|
|
|
* Locking note: This routine calls ext4_mb_init_cache(), which takes the
|
|
|
|
* block group lock of all groups for this page; do not hold the BG lock when
|
|
|
|
* calling this routine!
|
|
|
|
*/
|
2008-04-29 12:11:12 +00:00
|
|
|
static noinline_for_stack int
|
2016-03-13 21:29:06 +00:00
|
|
|
ext4_mb_load_buddy_gfp(struct super_block *sb, ext4_group_t group,
|
|
|
|
struct ext4_buddy *e4b, gfp_t gfp)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
|
|
|
int blocks_per_page;
|
|
|
|
int block;
|
|
|
|
int pnum;
|
|
|
|
int poff;
|
2024-04-16 17:28:54 +00:00
|
|
|
struct folio *folio;
|
2008-07-11 23:27:31 +00:00
|
|
|
int ret;
|
2009-01-06 02:36:19 +00:00
|
|
|
struct ext4_group_info *grp;
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
|
|
|
struct inode *inode = sbi->s_buddy_cache;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2013-04-04 02:00:52 +00:00
|
|
|
might_sleep();
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "load group %u\n", group);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros
PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time
ago with promise that one day it will be possible to implement page
cache with bigger chunks than PAGE_SIZE.
This promise never materialized. And unlikely will.
We have many places where PAGE_CACHE_SIZE assumed to be equal to
PAGE_SIZE. And it's constant source of confusion on whether
PAGE_CACHE_* or PAGE_* constant should be used in a particular case,
especially on the border between fs and mm.
Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
breakage to be doable.
Let's stop pretending that pages in page cache are special. They are
not.
The changes are pretty straight-forward:
- <foo> << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
- <foo> >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>;
- PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};
- page_cache_get() -> get_page();
- page_cache_release() -> put_page();
This patch contains automated changes generated with coccinelle using
script below. For some reason, coccinelle doesn't patch header files.
I've called spatch for them manually.
The only adjustment after coccinelle is revert of changes to
PAGE_CAHCE_ALIGN definition: we are going to drop it later.
There are few places in the code where coccinelle didn't reach. I'll
fix them manually in a separate patch. Comments and documentation also
will be addressed with the separate patch.
virtual patch
@@
expression E;
@@
- E << (PAGE_CACHE_SHIFT - PAGE_SHIFT)
+ E
@@
expression E;
@@
- E >> (PAGE_CACHE_SHIFT - PAGE_SHIFT)
+ E
@@
@@
- PAGE_CACHE_SHIFT
+ PAGE_SHIFT
@@
@@
- PAGE_CACHE_SIZE
+ PAGE_SIZE
@@
@@
- PAGE_CACHE_MASK
+ PAGE_MASK
@@
expression E;
@@
- PAGE_CACHE_ALIGN(E)
+ PAGE_ALIGN(E)
@@
expression E;
@@
- page_cache_get(E)
+ get_page(E)
@@
expression E;
@@
- page_cache_release(E)
+ put_page(E)
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-01 12:29:47 +00:00
|
|
|
blocks_per_page = PAGE_SIZE / sb->s_blocksize;
|
2009-01-06 02:36:19 +00:00
|
|
|
grp = ext4_get_group_info(sb, group);
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
if (!grp)
|
|
|
|
return -EFSCORRUPTED;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
e4b->bd_blkbits = sb->s_blocksize_bits;
|
2011-07-23 20:07:26 +00:00
|
|
|
e4b->bd_info = grp;
|
2008-01-29 05:19:52 +00:00
|
|
|
e4b->bd_sb = sb;
|
|
|
|
e4b->bd_group = group;
|
2024-04-16 17:28:55 +00:00
|
|
|
e4b->bd_buddy_folio = NULL;
|
2024-04-16 17:28:54 +00:00
|
|
|
e4b->bd_bitmap_folio = NULL;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2009-09-10 03:34:50 +00:00
|
|
|
if (unlikely(EXT4_MB_GRP_NEED_INIT(grp))) {
|
|
|
|
/*
|
|
|
|
* we need full data about the group
|
|
|
|
* to make a good selection
|
|
|
|
*/
|
2016-03-13 21:29:06 +00:00
|
|
|
ret = ext4_mb_init_group(sb, group, gfp);
|
2009-09-10 03:34:50 +00:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
/*
|
|
|
|
* the buddy cache inode stores the block bitmap
|
|
|
|
* and buddy information in consecutive blocks.
|
|
|
|
* So for each group we need two blocks.
|
|
|
|
*/
|
|
|
|
block = group * 2;
|
|
|
|
pnum = block / blocks_per_page;
|
|
|
|
poff = block % blocks_per_page;
|
|
|
|
|
2024-04-16 17:28:54 +00:00
|
|
|
/* Avoid locking the folio in the fast path ... */
|
|
|
|
folio = __filemap_get_folio(inode->i_mapping, pnum, FGP_ACCESSED, 0);
|
|
|
|
if (IS_ERR(folio) || !folio_test_uptodate(folio)) {
|
|
|
|
if (!IS_ERR(folio))
|
2009-01-06 02:36:19 +00:00
|
|
|
/*
|
2024-04-16 17:28:54 +00:00
|
|
|
* drop the folio reference and try
|
|
|
|
* to get the folio with lock. If we
|
2009-01-06 02:36:19 +00:00
|
|
|
* are not uptodate that implies
|
2024-04-16 17:28:54 +00:00
|
|
|
* somebody just created the folio but
|
|
|
|
* is yet to initialize it. So
|
2009-01-06 02:36:19 +00:00
|
|
|
* wait for it to initialize.
|
|
|
|
*/
|
2024-04-16 17:28:54 +00:00
|
|
|
folio_put(folio);
|
|
|
|
folio = __filemap_get_folio(inode->i_mapping, pnum,
|
|
|
|
FGP_LOCK | FGP_ACCESSED | FGP_CREAT, gfp);
|
|
|
|
if (!IS_ERR(folio)) {
|
|
|
|
if (WARN_RATELIMIT(folio->mapping != inode->i_mapping,
|
|
|
|
"ext4: bitmap's mapping != inode->i_mapping\n")) {
|
2023-03-16 21:07:32 +00:00
|
|
|
/* should never happen */
|
2024-04-16 17:28:54 +00:00
|
|
|
folio_unlock(folio);
|
2023-03-16 21:07:32 +00:00
|
|
|
ret = -EINVAL;
|
|
|
|
goto err;
|
|
|
|
}
|
2024-04-16 17:28:54 +00:00
|
|
|
if (!folio_test_uptodate(folio)) {
|
2024-04-16 17:28:56 +00:00
|
|
|
ret = ext4_mb_init_cache(folio, NULL, gfp);
|
2008-07-11 23:27:31 +00:00
|
|
|
if (ret) {
|
2024-04-16 17:28:54 +00:00
|
|
|
folio_unlock(folio);
|
2008-07-11 23:27:31 +00:00
|
|
|
goto err;
|
|
|
|
}
|
2024-04-16 17:28:54 +00:00
|
|
|
mb_cmp_bitmaps(e4b, folio_address(folio) +
|
2008-01-29 05:19:52 +00:00
|
|
|
(poff * sb->s_blocksize));
|
|
|
|
}
|
2024-04-16 17:28:54 +00:00
|
|
|
folio_unlock(folio);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
}
|
2024-04-16 17:28:54 +00:00
|
|
|
if (IS_ERR(folio)) {
|
|
|
|
ret = PTR_ERR(folio);
|
2014-04-11 03:03:43 +00:00
|
|
|
goto err;
|
|
|
|
}
|
2024-04-16 17:28:54 +00:00
|
|
|
if (!folio_test_uptodate(folio)) {
|
2008-07-11 23:27:31 +00:00
|
|
|
ret = -EIO;
|
2008-01-29 05:19:52 +00:00
|
|
|
goto err;
|
2008-07-11 23:27:31 +00:00
|
|
|
}
|
2014-06-04 23:10:31 +00:00
|
|
|
|
2024-04-16 17:28:55 +00:00
|
|
|
/* Folios marked accessed already */
|
2024-04-16 17:28:54 +00:00
|
|
|
e4b->bd_bitmap_folio = folio;
|
|
|
|
e4b->bd_bitmap = folio_address(folio) + (poff * sb->s_blocksize);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
block++;
|
|
|
|
pnum = block / blocks_per_page;
|
|
|
|
poff = block % blocks_per_page;
|
|
|
|
|
2024-04-16 17:28:55 +00:00
|
|
|
folio = __filemap_get_folio(inode->i_mapping, pnum, FGP_ACCESSED, 0);
|
|
|
|
if (IS_ERR(folio) || !folio_test_uptodate(folio)) {
|
|
|
|
if (!IS_ERR(folio))
|
|
|
|
folio_put(folio);
|
|
|
|
folio = __filemap_get_folio(inode->i_mapping, pnum,
|
|
|
|
FGP_LOCK | FGP_ACCESSED | FGP_CREAT, gfp);
|
|
|
|
if (!IS_ERR(folio)) {
|
|
|
|
if (WARN_RATELIMIT(folio->mapping != inode->i_mapping,
|
|
|
|
"ext4: buddy bitmap's mapping != inode->i_mapping\n")) {
|
2023-03-16 21:07:32 +00:00
|
|
|
/* should never happen */
|
2024-04-16 17:28:55 +00:00
|
|
|
folio_unlock(folio);
|
2023-03-16 21:07:32 +00:00
|
|
|
ret = -EINVAL;
|
|
|
|
goto err;
|
|
|
|
}
|
2024-04-16 17:28:55 +00:00
|
|
|
if (!folio_test_uptodate(folio)) {
|
2024-04-16 17:28:56 +00:00
|
|
|
ret = ext4_mb_init_cache(folio, e4b->bd_bitmap,
|
2016-03-13 21:29:06 +00:00
|
|
|
gfp);
|
2008-07-11 23:27:31 +00:00
|
|
|
if (ret) {
|
2024-04-16 17:28:55 +00:00
|
|
|
folio_unlock(folio);
|
2008-07-11 23:27:31 +00:00
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
}
|
2024-04-16 17:28:55 +00:00
|
|
|
folio_unlock(folio);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
}
|
2024-04-16 17:28:55 +00:00
|
|
|
if (IS_ERR(folio)) {
|
|
|
|
ret = PTR_ERR(folio);
|
2014-04-11 03:03:43 +00:00
|
|
|
goto err;
|
|
|
|
}
|
2024-04-16 17:28:55 +00:00
|
|
|
if (!folio_test_uptodate(folio)) {
|
2008-07-11 23:27:31 +00:00
|
|
|
ret = -EIO;
|
2008-01-29 05:19:52 +00:00
|
|
|
goto err;
|
2008-07-11 23:27:31 +00:00
|
|
|
}
|
2014-06-04 23:10:31 +00:00
|
|
|
|
2024-04-16 17:28:55 +00:00
|
|
|
/* Folios marked accessed already */
|
|
|
|
e4b->bd_buddy_folio = folio;
|
|
|
|
e4b->bd_buddy = folio_address(folio) + (poff * sb->s_blocksize);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err:
|
2024-05-10 15:22:53 +00:00
|
|
|
if (!IS_ERR_OR_NULL(folio))
|
2024-04-16 17:28:55 +00:00
|
|
|
folio_put(folio);
|
2024-04-16 17:28:54 +00:00
|
|
|
if (e4b->bd_bitmap_folio)
|
|
|
|
folio_put(e4b->bd_bitmap_folio);
|
2023-03-03 17:21:10 +00:00
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
e4b->bd_buddy = NULL;
|
|
|
|
e4b->bd_bitmap = NULL;
|
2008-07-11 23:27:31 +00:00
|
|
|
return ret;
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
2016-03-13 21:29:06 +00:00
|
|
|
static int ext4_mb_load_buddy(struct super_block *sb, ext4_group_t group,
|
|
|
|
struct ext4_buddy *e4b)
|
|
|
|
{
|
|
|
|
return ext4_mb_load_buddy_gfp(sb, group, e4b, GFP_NOFS);
|
|
|
|
}
|
|
|
|
|
2010-05-14 04:00:00 +00:00
|
|
|
static void ext4_mb_unload_buddy(struct ext4_buddy *e4b)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
2024-04-16 17:28:54 +00:00
|
|
|
if (e4b->bd_bitmap_folio)
|
|
|
|
folio_put(e4b->bd_bitmap_folio);
|
2024-04-16 17:28:55 +00:00
|
|
|
if (e4b->bd_buddy_folio)
|
|
|
|
folio_put(e4b->bd_buddy_folio);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static int mb_find_order_for_block(struct ext4_buddy *e4b, int block)
|
|
|
|
{
|
2020-11-07 15:58:13 +00:00
|
|
|
int order = 1, max;
|
2008-01-29 05:19:52 +00:00
|
|
|
void *bb;
|
|
|
|
|
2012-02-20 22:54:06 +00:00
|
|
|
BUG_ON(e4b->bd_bitmap == e4b->bd_buddy);
|
2008-01-29 05:19:52 +00:00
|
|
|
BUG_ON(block >= (1 << (e4b->bd_blkbits + 3)));
|
|
|
|
|
|
|
|
while (order <= e4b->bd_blkbits + 1) {
|
2020-11-07 15:58:13 +00:00
|
|
|
bb = mb_find_buddy(e4b, order, &max);
|
|
|
|
if (!mb_test_bit(block >> order, bb)) {
|
2008-01-29 05:19:52 +00:00
|
|
|
/* this block is part of buddy of order 'order' */
|
|
|
|
return order;
|
|
|
|
}
|
|
|
|
order++;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-05-03 00:35:09 +00:00
|
|
|
static void mb_clear_bits(void *bm, int cur, int len)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
|
|
|
__u32 *addr;
|
|
|
|
|
|
|
|
len = cur + len;
|
|
|
|
while (cur < len) {
|
|
|
|
if ((cur & 31) == 0 && (len - cur) >= 32) {
|
|
|
|
/* fast path: clear whole word at once */
|
|
|
|
addr = bm + (cur >> 3);
|
|
|
|
*addr = 0;
|
|
|
|
cur += 32;
|
|
|
|
continue;
|
|
|
|
}
|
2009-05-03 00:35:09 +00:00
|
|
|
mb_clear_bit(cur, bm);
|
2008-01-29 05:19:52 +00:00
|
|
|
cur++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-04-09 16:22:29 +00:00
|
|
|
/* clear bits in given range
|
|
|
|
* will return first found zero bit if any, -1 otherwise
|
|
|
|
*/
|
|
|
|
static int mb_test_and_clear_bits(void *bm, int cur, int len)
|
|
|
|
{
|
|
|
|
__u32 *addr;
|
|
|
|
int zero_bit = -1;
|
|
|
|
|
|
|
|
len = cur + len;
|
|
|
|
while (cur < len) {
|
|
|
|
if ((cur & 31) == 0 && (len - cur) >= 32) {
|
|
|
|
/* fast path: clear whole word at once */
|
|
|
|
addr = bm + (cur >> 3);
|
|
|
|
if (*addr != (__u32)(-1) && zero_bit == -1)
|
|
|
|
zero_bit = cur + mb_find_next_zero_bit(addr, 32, 0);
|
|
|
|
*addr = 0;
|
|
|
|
cur += 32;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!mb_test_and_clear_bit(cur, bm) && zero_bit == -1)
|
|
|
|
zero_bit = cur;
|
|
|
|
cur++;
|
|
|
|
}
|
|
|
|
|
|
|
|
return zero_bit;
|
|
|
|
}
|
|
|
|
|
2022-02-16 07:02:47 +00:00
|
|
|
void mb_set_bits(void *bm, int cur, int len)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
|
|
|
__u32 *addr;
|
|
|
|
|
|
|
|
len = cur + len;
|
|
|
|
while (cur < len) {
|
|
|
|
if ((cur & 31) == 0 && (len - cur) >= 32) {
|
|
|
|
/* fast path: set whole word at once */
|
|
|
|
addr = bm + (cur >> 3);
|
|
|
|
*addr = 0xffffffff;
|
|
|
|
cur += 32;
|
|
|
|
continue;
|
|
|
|
}
|
2009-05-03 00:35:09 +00:00
|
|
|
mb_set_bit(cur, bm);
|
2008-01-29 05:19:52 +00:00
|
|
|
cur++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-04-09 16:22:29 +00:00
|
|
|
static inline int mb_buddy_adjust_border(int* bit, void* bitmap, int side)
|
|
|
|
{
|
|
|
|
if (mb_test_bit(*bit + side, bitmap)) {
|
|
|
|
mb_clear_bit(*bit, bitmap);
|
|
|
|
(*bit) -= side;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
(*bit) += side;
|
|
|
|
mb_set_bit(*bit, bitmap);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void mb_buddy_mark_free(struct ext4_buddy *e4b, int first, int last)
|
|
|
|
{
|
|
|
|
int max;
|
|
|
|
int order = 1;
|
|
|
|
void *buddy = mb_find_buddy(e4b, order, &max);
|
|
|
|
|
|
|
|
while (buddy) {
|
|
|
|
void *buddy2;
|
|
|
|
|
|
|
|
/* Bits in range [first; last] are known to be set since
|
|
|
|
* corresponding blocks were allocated. Bits in range
|
|
|
|
* (first; last) will stay set because they form buddies on
|
|
|
|
* upper layer. We just deal with borders if they don't
|
|
|
|
* align with upper layer and then go up.
|
|
|
|
* Releasing entire group is all about clearing
|
|
|
|
* single bit of highest order buddy.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* Example:
|
|
|
|
* ---------------------------------
|
|
|
|
* | 1 | 1 | 1 | 1 |
|
|
|
|
* ---------------------------------
|
|
|
|
* | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
|
|
|
|
* ---------------------------------
|
|
|
|
* 0 1 2 3 4 5 6 7
|
|
|
|
* \_____________________/
|
|
|
|
*
|
|
|
|
* Neither [1] nor [6] is aligned to above layer.
|
|
|
|
* Left neighbour [0] is free, so mark it busy,
|
|
|
|
* decrease bb_counters and extend range to
|
|
|
|
* [0; 6]
|
|
|
|
* Right neighbour [7] is busy. It can't be coaleasced with [6], so
|
|
|
|
* mark [6] free, increase bb_counters and shrink range to
|
|
|
|
* [0; 5].
|
|
|
|
* Then shift range to [0; 2], go up and do the same.
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
if (first & 1)
|
|
|
|
e4b->bd_info->bb_counters[order] += mb_buddy_adjust_border(&first, buddy, -1);
|
|
|
|
if (!(last & 1))
|
|
|
|
e4b->bd_info->bb_counters[order] += mb_buddy_adjust_border(&last, buddy, 1);
|
|
|
|
if (first > last)
|
|
|
|
break;
|
|
|
|
order++;
|
|
|
|
|
2023-03-03 17:21:12 +00:00
|
|
|
buddy2 = mb_find_buddy(e4b, order, &max);
|
|
|
|
if (!buddy2) {
|
2013-04-09 16:22:29 +00:00
|
|
|
mb_clear_bits(buddy, first, last - first + 1);
|
|
|
|
e4b->bd_info->bb_counters[order - 1] += last - first + 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
first >>= 1;
|
|
|
|
last >>= 1;
|
|
|
|
buddy = buddy2;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-07-14 01:03:31 +00:00
|
|
|
static void mb_free_blocks(struct inode *inode, struct ext4_buddy *e4b,
|
2013-04-09 16:22:29 +00:00
|
|
|
int first, int count)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
2013-04-09 16:22:29 +00:00
|
|
|
int left_is_free = 0;
|
|
|
|
int right_is_free = 0;
|
|
|
|
int block;
|
|
|
|
int last = first + count - 1;
|
2008-01-29 05:19:52 +00:00
|
|
|
struct super_block *sb = e4b->bd_sb;
|
|
|
|
|
2014-08-23 21:47:28 +00:00
|
|
|
if (WARN_ON(count == 0))
|
|
|
|
return;
|
2013-04-09 16:22:29 +00:00
|
|
|
BUG_ON(last >= (sb->s_blocksize << 3));
|
2009-05-15 12:33:18 +00:00
|
|
|
assert_spin_locked(ext4_group_lock_ptr(sb, e4b->bd_group));
|
ext4: mark block group as corrupt on block bitmap error
When we notice a block-bitmap corruption (because of device failure or
something else), we should mark this group as corrupt and prevent
further block allocations/deallocations from it. Currently, we end up
generating one error message for every block in the bitmap. This
potentially could make the system unstable as noticed in some
bugs. With this patch, the error will be printed only the first time
and mark the entire block group as corrupted. This prevents future
access allocations/deallocations from it.
Also tested by corrupting the block
bitmap and forcefully introducing the mb_free_blocks error:
(1) create a largefile (2Gb)
$ dd if=/dev/zero of=largefile oflag=direct bs=10485760 count=200
(2) umount filesystem. use dumpe2fs to see which block-bitmaps
are in use by largefile and note their block numbers
(3) use dd to zero-out the used block bitmaps
$ dd if=/dev/zero of=/dev/hdc4 bs=4096 seek=14 count=8 oflag=direct
(4) mount the FS and delete the largefile.
(5) recreate the largefile. verify that the new largefile does not
get any blocks from the groups marked as bad.
Without the patch, we will see mb_free_blocks error for each bit in
each zero'ed out bitmap at (4). With the patch, we only see the error
once per blockgroup:
[ 309.706803] EXT4-fs error (device sdb4): ext4_mb_generate_buddy:735: group 15: 32768 clusters in bitmap, 0 in gd. blk grp corrupted.
[ 309.720824] EXT4-fs error (device sdb4): ext4_mb_generate_buddy:735: group 14: 32768 clusters in bitmap, 0 in gd. blk grp corrupted.
[ 309.732858] EXT4-fs error (device sdb4) in ext4_free_blocks:4802: IO failure
[ 309.748321] EXT4-fs error (device sdb4): ext4_mb_generate_buddy:735: group 13: 32768 clusters in bitmap, 0 in gd. blk grp corrupted.
[ 309.760331] EXT4-fs error (device sdb4) in ext4_free_blocks:4802: IO failure
[ 309.769695] EXT4-fs error (device sdb4): ext4_mb_generate_buddy:735: group 12: 32768 clusters in bitmap, 0 in gd. blk grp corrupted.
[ 309.781721] EXT4-fs error (device sdb4) in ext4_free_blocks:4802: IO failure
[ 309.798166] EXT4-fs error (device sdb4): ext4_mb_generate_buddy:735: group 11: 32768 clusters in bitmap, 0 in gd. blk grp corrupted.
[ 309.810184] EXT4-fs error (device sdb4) in ext4_free_blocks:4802: IO failure
[ 309.819532] EXT4-fs error (device sdb4): ext4_mb_generate_buddy:735: group 10: 32768 clusters in bitmap, 0 in gd. blk grp corrupted.
Google-Bug-Id: 7258357
[darrick.wong@oracle.com]
Further modifications (by Darrick) to make more obvious that this corruption
bit applies to blocks only. Set the corruption flag if the block group bitmap
verification fails.
Original-author: Aditya Kali <adityakali@google.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2013-08-28 21:35:51 +00:00
|
|
|
/* Don't bother if the block group is corrupt. */
|
|
|
|
if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)))
|
|
|
|
return;
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
mb_check_buddy(e4b);
|
|
|
|
mb_free_blocks_double(inode, e4b, first, count);
|
|
|
|
|
2013-04-09 16:22:29 +00:00
|
|
|
/* access memory sequentially: check left neighbour,
|
|
|
|
* clear range and then check right neighbour
|
|
|
|
*/
|
2008-01-29 05:19:52 +00:00
|
|
|
if (first != 0)
|
2013-04-09 16:22:29 +00:00
|
|
|
left_is_free = !mb_test_bit(first - 1, e4b->bd_bitmap);
|
|
|
|
block = mb_test_and_clear_bits(e4b->bd_bitmap, first, count);
|
|
|
|
if (last + 1 < EXT4_SB(sb)->s_mb_maxs[0])
|
|
|
|
right_is_free = !mb_test_bit(last + 1, e4b->bd_bitmap);
|
|
|
|
|
|
|
|
if (unlikely(block != -1)) {
|
2014-06-26 14:11:53 +00:00
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
2013-04-09 16:22:29 +00:00
|
|
|
ext4_fsblk_t blocknr;
|
|
|
|
|
2024-01-04 14:20:36 +00:00
|
|
|
/*
|
|
|
|
* Fastcommit replay can free already freed blocks which
|
|
|
|
* corrupts allocation info. Regenerate it.
|
|
|
|
*/
|
|
|
|
if (sbi->s_mount_state & EXT4_FC_REPLAY) {
|
|
|
|
mb_regenerate_buddy(e4b);
|
|
|
|
goto check;
|
|
|
|
}
|
|
|
|
|
2013-04-09 16:22:29 +00:00
|
|
|
blocknr = ext4_group_first_block_no(sb, e4b->bd_group);
|
2018-01-11 18:17:49 +00:00
|
|
|
blocknr += EXT4_C2B(sbi, block);
|
2024-01-04 14:20:40 +00:00
|
|
|
ext4_mark_group_bitmap_corrupted(sb, e4b->bd_group,
|
|
|
|
EXT4_GROUP_INFO_BBITMAP_CORRUPT);
|
2024-01-04 14:20:36 +00:00
|
|
|
ext4_grp_locked_error(sb, e4b->bd_group,
|
|
|
|
inode ? inode->i_ino : 0, blocknr,
|
|
|
|
"freeing already freed block (bit %u); block bitmap corrupt.",
|
|
|
|
block);
|
|
|
|
return;
|
2013-04-09 16:22:29 +00:00
|
|
|
}
|
|
|
|
|
2024-01-04 14:20:36 +00:00
|
|
|
this_cpu_inc(discard_pa_seq);
|
|
|
|
e4b->bd_info->bb_free += count;
|
|
|
|
if (first < e4b->bd_info->bb_first_free)
|
|
|
|
e4b->bd_info->bb_first_free = first;
|
|
|
|
|
2013-04-09 16:22:29 +00:00
|
|
|
/* let's maintain fragments counter */
|
|
|
|
if (left_is_free && right_is_free)
|
2008-01-29 05:19:52 +00:00
|
|
|
e4b->bd_info->bb_fragments--;
|
2013-04-09 16:22:29 +00:00
|
|
|
else if (!left_is_free && !right_is_free)
|
2008-01-29 05:19:52 +00:00
|
|
|
e4b->bd_info->bb_fragments++;
|
|
|
|
|
2013-04-09 16:22:29 +00:00
|
|
|
/* buddy[0] == bd_bitmap is a special case, so handle
|
|
|
|
* it right away and let mb_buddy_mark_free stay free of
|
|
|
|
* zero order checks.
|
|
|
|
* Check if neighbours are to be coaleasced,
|
|
|
|
* adjust bitmap bb_counters and borders appropriately.
|
|
|
|
*/
|
|
|
|
if (first & 1) {
|
|
|
|
first += !left_is_free;
|
|
|
|
e4b->bd_info->bb_counters[0] += left_is_free ? -1 : 1;
|
|
|
|
}
|
|
|
|
if (!(last & 1)) {
|
|
|
|
last -= !right_is_free;
|
|
|
|
e4b->bd_info->bb_counters[0] += right_is_free ? -1 : 1;
|
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2013-04-09 16:22:29 +00:00
|
|
|
if (first <= last)
|
|
|
|
mb_buddy_mark_free(e4b, first >> 1, last >> 1);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2010-05-16 19:00:00 +00:00
|
|
|
mb_set_largest_free_order(sb, e4b->bd_info);
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
mb_update_avg_fragment_size(sb, e4b->bd_info);
|
2024-01-04 14:20:36 +00:00
|
|
|
check:
|
2008-01-29 05:19:52 +00:00
|
|
|
mb_check_buddy(e4b);
|
|
|
|
}
|
|
|
|
|
2012-08-17 14:02:17 +00:00
|
|
|
static int mb_find_extent(struct ext4_buddy *e4b, int block,
|
2008-01-29 05:19:52 +00:00
|
|
|
int needed, struct ext4_free_extent *ex)
|
|
|
|
{
|
2023-11-13 08:26:17 +00:00
|
|
|
int max, order, next;
|
2008-01-29 05:19:52 +00:00
|
|
|
void *buddy;
|
|
|
|
|
2009-05-15 12:33:18 +00:00
|
|
|
assert_spin_locked(ext4_group_lock_ptr(e4b->bd_sb, e4b->bd_group));
|
2008-01-29 05:19:52 +00:00
|
|
|
BUG_ON(ex == NULL);
|
|
|
|
|
2012-08-17 14:02:17 +00:00
|
|
|
buddy = mb_find_buddy(e4b, 0, &max);
|
2008-01-29 05:19:52 +00:00
|
|
|
BUG_ON(buddy == NULL);
|
|
|
|
BUG_ON(block >= max);
|
|
|
|
if (mb_test_bit(block, buddy)) {
|
|
|
|
ex->fe_len = 0;
|
|
|
|
ex->fe_start = 0;
|
|
|
|
ex->fe_group = 0;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-08-17 14:02:17 +00:00
|
|
|
/* find actual order */
|
|
|
|
order = mb_find_order_for_block(e4b, block);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2023-11-13 08:26:17 +00:00
|
|
|
ex->fe_len = (1 << order) - (block & ((1 << order) - 1));
|
|
|
|
ex->fe_start = block;
|
2008-01-29 05:19:52 +00:00
|
|
|
ex->fe_group = e4b->bd_group;
|
|
|
|
|
2023-11-13 08:26:17 +00:00
|
|
|
block = block >> order;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
while (needed > ex->fe_len &&
|
2012-11-08 17:19:58 +00:00
|
|
|
mb_find_buddy(e4b, order, &max)) {
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
if (block + 1 >= max)
|
|
|
|
break;
|
|
|
|
|
|
|
|
next = (block + 1) * (1 << order);
|
2012-02-20 22:54:06 +00:00
|
|
|
if (mb_test_bit(next, e4b->bd_bitmap))
|
2008-01-29 05:19:52 +00:00
|
|
|
break;
|
|
|
|
|
2011-10-26 09:30:30 +00:00
|
|
|
order = mb_find_order_for_block(e4b, next);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
block = next >> order;
|
|
|
|
ex->fe_len += 1 << order;
|
|
|
|
}
|
|
|
|
|
2019-04-06 22:33:06 +00:00
|
|
|
if (ex->fe_start + ex->fe_len > EXT4_CLUSTERS_PER_GROUP(e4b->bd_sb)) {
|
2017-01-23 00:35:52 +00:00
|
|
|
/* Should never happen! (but apparently sometimes does?!?) */
|
|
|
|
WARN_ON(1);
|
2021-06-23 23:21:14 +00:00
|
|
|
ext4_grp_locked_error(e4b->bd_sb, e4b->bd_group, 0, 0,
|
|
|
|
"corruption or bug in mb_find_extent "
|
|
|
|
"block=%d, order=%d needed=%d ex=%u/%d/%d@%u",
|
|
|
|
block, order, needed, ex->fe_group, ex->fe_start,
|
|
|
|
ex->fe_len, ex->fe_logical);
|
2017-01-23 00:35:52 +00:00
|
|
|
ex->fe_len = 0;
|
|
|
|
ex->fe_start = 0;
|
|
|
|
ex->fe_group = 0;
|
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
return ex->fe_len;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int mb_mark_used(struct ext4_buddy *e4b, struct ext4_free_extent *ex)
|
|
|
|
{
|
|
|
|
int ord;
|
|
|
|
int mlen = 0;
|
|
|
|
int max = 0;
|
|
|
|
int start = ex->fe_start;
|
|
|
|
int len = ex->fe_len;
|
|
|
|
unsigned ret = 0;
|
|
|
|
int len0 = len;
|
|
|
|
void *buddy;
|
2024-04-24 06:19:02 +00:00
|
|
|
int ord_start, ord_end;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
BUG_ON(start + len > (e4b->bd_sb->s_blocksize << 3));
|
|
|
|
BUG_ON(e4b->bd_group != ex->fe_group);
|
2009-05-15 12:33:18 +00:00
|
|
|
assert_spin_locked(ext4_group_lock_ptr(e4b->bd_sb, e4b->bd_group));
|
2008-01-29 05:19:52 +00:00
|
|
|
mb_check_buddy(e4b);
|
|
|
|
mb_mark_used_double(e4b, start, len);
|
|
|
|
|
ext4: mballoc: introduce pcpu seqcnt for freeing PA to improve ENOSPC handling
There could be a race in function ext4_mb_discard_group_preallocations()
where the 1st thread may iterate through group's bb_prealloc_list and
remove all the PAs and add to function's local list head.
Now if the 2nd thread comes in to discard the group preallocations,
it will see that the group->bb_prealloc_list is empty and will return 0.
Consider for a case where we have less number of groups
(for e.g. just group 0),
this may even return an -ENOSPC error from ext4_mb_new_blocks()
(where we call for ext4_mb_discard_group_preallocations()).
But that is wrong, since 2nd thread should have waited for 1st thread
to release all the PAs and should have retried for allocation.
Since 1st thread was anyway going to discard the PAs.
The algorithm using this percpu seq counter goes below:
1. We sample the percpu discard_pa_seq counter before trying for block
allocation in ext4_mb_new_blocks().
2. We increment this percpu discard_pa_seq counter when we either allocate
or free these blocks i.e. while marking those blocks as used/free in
mb_mark_used()/mb_free_blocks().
3. We also increment this percpu seq counter when we successfully identify
that the bb_prealloc_list is not empty and hence proceed for discarding
of those PAs inside ext4_mb_discard_group_preallocations().
Now to make sure that the regular fast path of block allocation is not
affected, as a small optimization we only sample the percpu seq counter
on that cpu. Only when the block allocation fails and when freed blocks
found were 0, that is when we sample percpu seq counter for all cpus using
below function ext4_get_discard_pa_seq_sum(). This happens after making
sure that all the PAs on grp->bb_prealloc_list got freed or if it's empty.
It can be well argued that why don't just check for grp->bb_free to
see if there are any free blocks to be allocated. So here are the two
concerns which were discussed:-
1. If for some reason the blocks available in the group are not
appropriate for allocation logic (say for e.g.
EXT4_MB_HINT_GOAL_ONLY, although this is not yet implemented), then
the retry logic may result into infinte looping since grp->bb_free is
non-zero.
2. Also before preallocation was clubbed with block allocation with the
same ext4_lock_group() held, there were lot of races where grp->bb_free
could not be reliably relied upon.
Due to above, this patch considers discard_pa_seq logic to determine if
we should retry for block allocation. Say if there are are n threads
trying for block allocation and none of those could allocate or discard
any of the blocks, then all of those n threads will fail the block
allocation and return -ENOSPC error. (Since the seq counter for all of
those will match as no block allocation/discard was done during that
duration).
Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
Link: https://lore.kernel.org/r/7f254686903b87c419d798742fd9a1be34f0657b.1589955723.git.riteshh@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2020-05-20 06:40:34 +00:00
|
|
|
this_cpu_inc(discard_pa_seq);
|
2008-01-29 05:19:52 +00:00
|
|
|
e4b->bd_info->bb_free -= len;
|
|
|
|
if (e4b->bd_info->bb_first_free == start)
|
|
|
|
e4b->bd_info->bb_first_free += len;
|
|
|
|
|
|
|
|
/* let's maintain fragments counter */
|
|
|
|
if (start != 0)
|
2012-02-20 22:54:06 +00:00
|
|
|
mlen = !mb_test_bit(start - 1, e4b->bd_bitmap);
|
2008-01-29 05:19:52 +00:00
|
|
|
if (start + len < EXT4_SB(e4b->bd_sb)->s_mb_maxs[0])
|
2012-02-20 22:54:06 +00:00
|
|
|
max = !mb_test_bit(start + len, e4b->bd_bitmap);
|
2008-01-29 05:19:52 +00:00
|
|
|
if (mlen && max)
|
|
|
|
e4b->bd_info->bb_fragments++;
|
|
|
|
else if (!mlen && !max)
|
|
|
|
e4b->bd_info->bb_fragments--;
|
|
|
|
|
|
|
|
/* let's maintain buddy itself */
|
|
|
|
while (len) {
|
2024-04-24 06:19:02 +00:00
|
|
|
ord = mb_find_order_for_block(e4b, start);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
if (((start >> ord) << ord) == start && len >= (1 << ord)) {
|
|
|
|
/* the whole chunk may be allocated at once! */
|
|
|
|
mlen = 1 << ord;
|
2024-04-24 06:19:02 +00:00
|
|
|
buddy = mb_find_buddy(e4b, ord, &max);
|
2008-01-29 05:19:52 +00:00
|
|
|
BUG_ON((start >> ord) >= max);
|
|
|
|
mb_set_bit(start >> ord, buddy);
|
|
|
|
e4b->bd_info->bb_counters[ord]--;
|
|
|
|
start += mlen;
|
|
|
|
len -= mlen;
|
|
|
|
BUG_ON(len < 0);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* store for history */
|
|
|
|
if (ret == 0)
|
|
|
|
ret = len | (ord << 16);
|
|
|
|
|
|
|
|
BUG_ON(ord <= 0);
|
|
|
|
buddy = mb_find_buddy(e4b, ord, &max);
|
|
|
|
mb_set_bit(start >> ord, buddy);
|
|
|
|
e4b->bd_info->bb_counters[ord]--;
|
|
|
|
|
2024-04-24 06:19:02 +00:00
|
|
|
ord_start = (start >> ord) << ord;
|
|
|
|
ord_end = ord_start + (1 << ord);
|
|
|
|
/* first chunk */
|
|
|
|
if (start > ord_start)
|
|
|
|
ext4_mb_mark_free_simple(e4b->bd_sb, e4b->bd_buddy,
|
|
|
|
ord_start, start - ord_start,
|
|
|
|
e4b->bd_info);
|
|
|
|
|
|
|
|
/* last chunk */
|
|
|
|
if (start + len < ord_end) {
|
|
|
|
ext4_mb_mark_free_simple(e4b->bd_sb, e4b->bd_buddy,
|
|
|
|
start + len,
|
|
|
|
ord_end - (start + len),
|
|
|
|
e4b->bd_info);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
len = start + len - ord_end;
|
|
|
|
start = ord_end;
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2010-05-16 19:00:00 +00:00
|
|
|
mb_set_largest_free_order(e4b->bd_sb, e4b->bd_info);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
mb_update_avg_fragment_size(e4b->bd_sb, e4b->bd_info);
|
2022-02-16 07:02:47 +00:00
|
|
|
mb_set_bits(e4b->bd_bitmap, ex->fe_start, len0);
|
2008-01-29 05:19:52 +00:00
|
|
|
mb_check_buddy(e4b);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Must be called under group lock!
|
|
|
|
*/
|
|
|
|
static void ext4_mb_use_best_found(struct ext4_allocation_context *ac,
|
|
|
|
struct ext4_buddy *e4b)
|
|
|
|
{
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(ac->ac_sb);
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
BUG_ON(ac->ac_b_ex.fe_group != e4b->bd_group);
|
|
|
|
BUG_ON(ac->ac_status == AC_STATUS_FOUND);
|
|
|
|
|
|
|
|
ac->ac_b_ex.fe_len = min(ac->ac_b_ex.fe_len, ac->ac_g_ex.fe_len);
|
|
|
|
ac->ac_b_ex.fe_logical = ac->ac_g_ex.fe_logical;
|
|
|
|
ret = mb_mark_used(e4b, &ac->ac_b_ex);
|
|
|
|
|
|
|
|
/* preallocation can change ac_b_ex, thus we store actually
|
|
|
|
* allocated blocks for history */
|
|
|
|
ac->ac_f_ex = ac->ac_b_ex;
|
|
|
|
|
|
|
|
ac->ac_status = AC_STATUS_FOUND;
|
|
|
|
ac->ac_tail = ret & 0xffff;
|
|
|
|
ac->ac_buddy = ret >> 16;
|
|
|
|
|
2008-11-25 20:11:52 +00:00
|
|
|
/*
|
|
|
|
* take the page reference. We want the page to be pinned
|
|
|
|
* so that we don't get a ext4_mb_init_cache_call for this
|
|
|
|
* group until we update the bitmap. That would mean we
|
|
|
|
* double allocate blocks. The reference is dropped
|
|
|
|
* in ext4_mb_release_context
|
|
|
|
*/
|
2024-04-16 17:28:57 +00:00
|
|
|
ac->ac_bitmap_folio = e4b->bd_bitmap_folio;
|
|
|
|
folio_get(ac->ac_bitmap_folio);
|
2024-04-16 17:28:58 +00:00
|
|
|
ac->ac_buddy_folio = e4b->bd_buddy_folio;
|
|
|
|
folio_get(ac->ac_buddy_folio);
|
2008-01-29 05:19:52 +00:00
|
|
|
/* store last allocated for subsequent stream allocation */
|
2009-08-10 02:01:13 +00:00
|
|
|
if (ac->ac_flags & EXT4_MB_STREAM_ALLOC) {
|
2008-01-29 05:19:52 +00:00
|
|
|
spin_lock(&sbi->s_md_lock);
|
|
|
|
sbi->s_mb_last_group = ac->ac_f_ex.fe_group;
|
|
|
|
sbi->s_mb_last_start = ac->ac_f_ex.fe_start;
|
|
|
|
spin_unlock(&sbi->s_md_lock);
|
|
|
|
}
|
2020-05-20 06:40:32 +00:00
|
|
|
/*
|
|
|
|
* As we've just preallocated more space than
|
|
|
|
* user requested originally, we store allocated
|
|
|
|
* space in a special descriptor.
|
|
|
|
*/
|
|
|
|
if (ac->ac_o_ex.fe_len < ac->ac_b_ex.fe_len)
|
|
|
|
ext4_mb_new_preallocation(ac);
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void ext4_mb_check_limits(struct ext4_allocation_context *ac,
|
|
|
|
struct ext4_buddy *e4b,
|
|
|
|
int finish_group)
|
|
|
|
{
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(ac->ac_sb);
|
|
|
|
struct ext4_free_extent *bex = &ac->ac_b_ex;
|
|
|
|
struct ext4_free_extent *gex = &ac->ac_g_ex;
|
|
|
|
|
2009-01-06 02:34:30 +00:00
|
|
|
if (ac->ac_status == AC_STATUS_FOUND)
|
|
|
|
return;
|
2008-01-29 05:19:52 +00:00
|
|
|
/*
|
|
|
|
* We don't want to scan for a whole year
|
|
|
|
*/
|
|
|
|
if (ac->ac_found > sbi->s_mb_max_to_scan &&
|
|
|
|
!(ac->ac_flags & EXT4_MB_HINT_FIRST)) {
|
|
|
|
ac->ac_status = AC_STATUS_BREAK;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Haven't found good chunk so far, let's continue
|
|
|
|
*/
|
|
|
|
if (bex->fe_len < gex->fe_len)
|
|
|
|
return;
|
|
|
|
|
2023-05-30 12:33:39 +00:00
|
|
|
if (finish_group || ac->ac_found > sbi->s_mb_min_to_scan)
|
2023-03-03 17:21:14 +00:00
|
|
|
ext4_mb_use_best_found(ac, e4b);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The routine checks whether found extent is good enough. If it is,
|
|
|
|
* then the extent gets marked used and flag is set to the context
|
|
|
|
* to stop scanning. Otherwise, the extent is compared with the
|
|
|
|
* previous found extent and if new one is better, then it's stored
|
|
|
|
* in the context. Later, the best found extent will be used, if
|
|
|
|
* mballoc can't find good enough extent.
|
|
|
|
*
|
2023-05-30 12:33:39 +00:00
|
|
|
* The algorithm used is roughly as follows:
|
|
|
|
*
|
|
|
|
* * If free extent found is exactly as big as goal, then
|
|
|
|
* stop the scan and use it immediately
|
|
|
|
*
|
|
|
|
* * If free extent found is smaller than goal, then keep retrying
|
|
|
|
* upto a max of sbi->s_mb_max_to_scan times (default 200). After
|
|
|
|
* that stop scanning and use whatever we have.
|
|
|
|
*
|
|
|
|
* * If free extent found is bigger than goal, then keep retrying
|
|
|
|
* upto a max of sbi->s_mb_min_to_scan times (default 10) before
|
|
|
|
* stopping the scan and using the extent.
|
|
|
|
*
|
|
|
|
*
|
2008-01-29 05:19:52 +00:00
|
|
|
* FIXME: real allocation policy is to be designed yet!
|
|
|
|
*/
|
|
|
|
static void ext4_mb_measure_extent(struct ext4_allocation_context *ac,
|
|
|
|
struct ext4_free_extent *ex,
|
|
|
|
struct ext4_buddy *e4b)
|
|
|
|
{
|
|
|
|
struct ext4_free_extent *bex = &ac->ac_b_ex;
|
|
|
|
struct ext4_free_extent *gex = &ac->ac_g_ex;
|
|
|
|
|
|
|
|
BUG_ON(ex->fe_len <= 0);
|
2011-09-09 22:38:51 +00:00
|
|
|
BUG_ON(ex->fe_len > EXT4_CLUSTERS_PER_GROUP(ac->ac_sb));
|
|
|
|
BUG_ON(ex->fe_start >= EXT4_CLUSTERS_PER_GROUP(ac->ac_sb));
|
2008-01-29 05:19:52 +00:00
|
|
|
BUG_ON(ac->ac_status != AC_STATUS_CONTINUE);
|
|
|
|
|
|
|
|
ac->ac_found++;
|
2023-05-30 12:33:43 +00:00
|
|
|
ac->ac_cX_found[ac->ac_criteria]++;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The special case - take what you catch first
|
|
|
|
*/
|
|
|
|
if (unlikely(ac->ac_flags & EXT4_MB_HINT_FIRST)) {
|
|
|
|
*bex = *ex;
|
|
|
|
ext4_mb_use_best_found(ac, e4b);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Let's check whether the chuck is good enough
|
|
|
|
*/
|
|
|
|
if (ex->fe_len == gex->fe_len) {
|
|
|
|
*bex = *ex;
|
|
|
|
ext4_mb_use_best_found(ac, e4b);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If this is first found extent, just store it in the context
|
|
|
|
*/
|
|
|
|
if (bex->fe_len == 0) {
|
|
|
|
*bex = *ex;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If new found extent is better, store it in the context
|
|
|
|
*/
|
|
|
|
if (bex->fe_len < gex->fe_len) {
|
|
|
|
/* if the request isn't satisfied, any found extent
|
|
|
|
* larger than previous best one is better */
|
|
|
|
if (ex->fe_len > bex->fe_len)
|
|
|
|
*bex = *ex;
|
|
|
|
} else if (ex->fe_len > gex->fe_len) {
|
|
|
|
/* if the request is satisfied, then we try to find
|
|
|
|
* an extent that still satisfy the request, but is
|
|
|
|
* smaller than previous one */
|
|
|
|
if (ex->fe_len < bex->fe_len)
|
|
|
|
*bex = *ex;
|
|
|
|
}
|
|
|
|
|
|
|
|
ext4_mb_check_limits(ac, e4b, 0);
|
|
|
|
}
|
|
|
|
|
2009-07-06 02:17:31 +00:00
|
|
|
static noinline_for_stack
|
2023-03-03 17:21:08 +00:00
|
|
|
void ext4_mb_try_best_found(struct ext4_allocation_context *ac,
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_buddy *e4b)
|
|
|
|
{
|
|
|
|
struct ext4_free_extent ex = ac->ac_b_ex;
|
|
|
|
ext4_group_t group = ex.fe_group;
|
|
|
|
int max;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
BUG_ON(ex.fe_len <= 0);
|
|
|
|
err = ext4_mb_load_buddy(ac->ac_sb, group, e4b);
|
|
|
|
if (err)
|
2023-03-03 17:21:08 +00:00
|
|
|
return;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
ext4_lock_group(ac->ac_sb, group);
|
2024-01-04 14:20:38 +00:00
|
|
|
if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)))
|
|
|
|
goto out;
|
|
|
|
|
2012-08-17 14:02:17 +00:00
|
|
|
max = mb_find_extent(e4b, ex.fe_start, ex.fe_len, &ex);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
if (max > 0) {
|
|
|
|
ac->ac_b_ex = ex;
|
|
|
|
ext4_mb_use_best_found(ac, e4b);
|
|
|
|
}
|
|
|
|
|
2024-01-04 14:20:38 +00:00
|
|
|
out:
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_unlock_group(ac->ac_sb, group);
|
2010-05-14 04:00:00 +00:00
|
|
|
ext4_mb_unload_buddy(e4b);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
2009-07-06 02:17:31 +00:00
|
|
|
static noinline_for_stack
|
|
|
|
int ext4_mb_find_by_goal(struct ext4_allocation_context *ac,
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_buddy *e4b)
|
|
|
|
{
|
|
|
|
ext4_group_t group = ac->ac_g_ex.fe_group;
|
|
|
|
int max;
|
|
|
|
int err;
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(ac->ac_sb);
|
2012-09-24 03:10:51 +00:00
|
|
|
struct ext4_group_info *grp = ext4_get_group_info(ac->ac_sb, group);
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_free_extent ex;
|
|
|
|
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
if (!grp)
|
|
|
|
return -EFSCORRUPTED;
|
2023-03-03 17:21:02 +00:00
|
|
|
if (!(ac->ac_flags & (EXT4_MB_HINT_TRY_GOAL | EXT4_MB_HINT_GOAL_ONLY)))
|
2008-01-29 05:19:52 +00:00
|
|
|
return 0;
|
2012-09-24 03:10:51 +00:00
|
|
|
if (grp->bb_free == 0)
|
|
|
|
return 0;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
err = ext4_mb_load_buddy(ac->ac_sb, group, e4b);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
ext4_lock_group(ac->ac_sb, group);
|
2024-01-04 14:20:39 +00:00
|
|
|
if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)))
|
|
|
|
goto out;
|
|
|
|
|
2012-08-17 14:02:17 +00:00
|
|
|
max = mb_find_extent(e4b, ac->ac_g_ex.fe_start,
|
2008-01-29 05:19:52 +00:00
|
|
|
ac->ac_g_ex.fe_len, &ex);
|
2014-02-20 05:36:41 +00:00
|
|
|
ex.fe_logical = 0xDEADFA11; /* debug value */
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2023-06-03 15:03:12 +00:00
|
|
|
if (max >= ac->ac_g_ex.fe_len &&
|
2024-08-30 07:20:58 +00:00
|
|
|
ac->ac_g_ex.fe_len == EXT4_NUM_B2C(sbi, sbi->s_stripe)) {
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_fsblk_t start;
|
|
|
|
|
2023-06-03 15:03:11 +00:00
|
|
|
start = ext4_grp_offs_to_block(ac->ac_sb, &ex);
|
2008-01-29 05:19:52 +00:00
|
|
|
/* use do_div to get remainder (would be 64-bit modulo) */
|
|
|
|
if (do_div(start, sbi->s_stripe) == 0) {
|
|
|
|
ac->ac_found++;
|
|
|
|
ac->ac_b_ex = ex;
|
|
|
|
ext4_mb_use_best_found(ac, e4b);
|
|
|
|
}
|
|
|
|
} else if (max >= ac->ac_g_ex.fe_len) {
|
|
|
|
BUG_ON(ex.fe_len <= 0);
|
|
|
|
BUG_ON(ex.fe_group != ac->ac_g_ex.fe_group);
|
|
|
|
BUG_ON(ex.fe_start != ac->ac_g_ex.fe_start);
|
|
|
|
ac->ac_found++;
|
|
|
|
ac->ac_b_ex = ex;
|
|
|
|
ext4_mb_use_best_found(ac, e4b);
|
|
|
|
} else if (max > 0 && (ac->ac_flags & EXT4_MB_HINT_MERGE)) {
|
|
|
|
/* Sometimes, caller may want to merge even small
|
|
|
|
* number of blocks to an existing extent */
|
|
|
|
BUG_ON(ex.fe_len <= 0);
|
|
|
|
BUG_ON(ex.fe_group != ac->ac_g_ex.fe_group);
|
|
|
|
BUG_ON(ex.fe_start != ac->ac_g_ex.fe_start);
|
|
|
|
ac->ac_found++;
|
|
|
|
ac->ac_b_ex = ex;
|
|
|
|
ext4_mb_use_best_found(ac, e4b);
|
|
|
|
}
|
2024-01-04 14:20:39 +00:00
|
|
|
out:
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_unlock_group(ac->ac_sb, group);
|
2010-05-14 04:00:00 +00:00
|
|
|
ext4_mb_unload_buddy(e4b);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The routine scans buddy structures (not bitmap!) from given order
|
|
|
|
* to max order and tries to find big enough chunk to satisfy the req
|
|
|
|
*/
|
2009-07-06 02:17:31 +00:00
|
|
|
static noinline_for_stack
|
|
|
|
void ext4_mb_simple_scan_group(struct ext4_allocation_context *ac,
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_buddy *e4b)
|
|
|
|
{
|
|
|
|
struct super_block *sb = ac->ac_sb;
|
|
|
|
struct ext4_group_info *grp = e4b->bd_info;
|
|
|
|
void *buddy;
|
|
|
|
int i;
|
|
|
|
int k;
|
|
|
|
int max;
|
|
|
|
|
|
|
|
BUG_ON(ac->ac_2order <= 0);
|
2021-04-01 17:21:26 +00:00
|
|
|
for (i = ac->ac_2order; i < MB_NUM_ORDERS(sb); i++) {
|
2008-01-29 05:19:52 +00:00
|
|
|
if (grp->bb_counters[i] == 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
buddy = mb_find_buddy(e4b, i, &max);
|
2023-03-16 21:07:32 +00:00
|
|
|
if (WARN_RATELIMIT(buddy == NULL,
|
|
|
|
"ext4: mb_simple_scan_group: mb_find_buddy failed, (%d)\n", i))
|
|
|
|
continue;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2008-02-23 06:38:34 +00:00
|
|
|
k = mb_find_next_zero_bit(buddy, max, 0);
|
2020-03-10 15:01:56 +00:00
|
|
|
if (k >= max) {
|
2024-01-04 14:20:40 +00:00
|
|
|
ext4_mark_group_bitmap_corrupted(ac->ac_sb,
|
|
|
|
e4b->bd_group,
|
|
|
|
EXT4_GROUP_INFO_BBITMAP_CORRUPT);
|
2020-03-10 15:01:56 +00:00
|
|
|
ext4_grp_locked_error(ac->ac_sb, e4b->bd_group, 0, 0,
|
|
|
|
"%d free clusters of order %d. But found 0",
|
|
|
|
grp->bb_counters[i], i);
|
|
|
|
break;
|
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
ac->ac_found++;
|
2023-05-30 12:33:43 +00:00
|
|
|
ac->ac_cX_found[ac->ac_criteria]++;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
ac->ac_b_ex.fe_len = 1 << i;
|
|
|
|
ac->ac_b_ex.fe_start = k << i;
|
|
|
|
ac->ac_b_ex.fe_group = e4b->bd_group;
|
|
|
|
|
|
|
|
ext4_mb_use_best_found(ac, e4b);
|
|
|
|
|
2020-05-20 06:40:32 +00:00
|
|
|
BUG_ON(ac->ac_f_ex.fe_len != ac->ac_g_ex.fe_len);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
if (EXT4_SB(sb)->s_mb_stats)
|
|
|
|
atomic_inc(&EXT4_SB(sb)->s_bal_2orders);
|
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The routine scans the group and measures all found extents.
|
|
|
|
* In order to optimize scanning, caller must pass number of
|
|
|
|
* free blocks in the group, so the routine can know upper limit.
|
|
|
|
*/
|
2009-07-06 02:17:31 +00:00
|
|
|
static noinline_for_stack
|
|
|
|
void ext4_mb_complex_scan_group(struct ext4_allocation_context *ac,
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_buddy *e4b)
|
|
|
|
{
|
|
|
|
struct super_block *sb = ac->ac_sb;
|
2012-02-20 22:54:06 +00:00
|
|
|
void *bitmap = e4b->bd_bitmap;
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_free_extent ex;
|
2023-05-30 12:33:45 +00:00
|
|
|
int i, j, freelen;
|
2008-01-29 05:19:52 +00:00
|
|
|
int free;
|
|
|
|
|
|
|
|
free = e4b->bd_info->bb_free;
|
2020-04-14 03:33:05 +00:00
|
|
|
if (WARN_ON(free <= 0))
|
|
|
|
return;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
i = e4b->bd_info->bb_first_free;
|
|
|
|
|
|
|
|
while (free && ac->ac_status == AC_STATUS_CONTINUE) {
|
2008-02-23 06:38:34 +00:00
|
|
|
i = mb_find_next_zero_bit(bitmap,
|
2011-09-09 22:38:51 +00:00
|
|
|
EXT4_CLUSTERS_PER_GROUP(sb), i);
|
|
|
|
if (i >= EXT4_CLUSTERS_PER_GROUP(sb)) {
|
2008-02-10 06:10:04 +00:00
|
|
|
/*
|
2008-02-15 18:48:21 +00:00
|
|
|
* IF we have corrupt bitmap, we won't find any
|
2008-02-10 06:10:04 +00:00
|
|
|
* free blocks even though group info says we
|
2020-08-05 02:48:50 +00:00
|
|
|
* have free blocks
|
2008-02-10 06:10:04 +00:00
|
|
|
*/
|
2024-01-04 14:20:40 +00:00
|
|
|
ext4_mark_group_bitmap_corrupted(sb, e4b->bd_group,
|
|
|
|
EXT4_GROUP_INFO_BBITMAP_CORRUPT);
|
2010-06-29 16:54:28 +00:00
|
|
|
ext4_grp_locked_error(sb, e4b->bd_group, 0, 0,
|
2011-09-09 22:48:51 +00:00
|
|
|
"%d free clusters as per "
|
2009-01-06 03:17:35 +00:00
|
|
|
"group info. But bitmap says 0",
|
2008-02-10 06:10:04 +00:00
|
|
|
free);
|
2008-01-29 05:19:52 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2023-06-30 08:59:27 +00:00
|
|
|
if (!ext4_mb_cr_expensive(ac->ac_criteria)) {
|
2023-05-30 12:33:45 +00:00
|
|
|
/*
|
2023-05-30 12:33:50 +00:00
|
|
|
* In CR_GOAL_LEN_FAST and CR_BEST_AVAIL_LEN, we are
|
|
|
|
* sure that this group will have a large enough
|
|
|
|
* continuous free extent, so skip over the smaller free
|
|
|
|
* extents
|
2023-05-30 12:33:45 +00:00
|
|
|
*/
|
|
|
|
j = mb_find_next_bit(bitmap,
|
|
|
|
EXT4_CLUSTERS_PER_GROUP(sb), i);
|
|
|
|
freelen = j - i;
|
|
|
|
|
|
|
|
if (freelen < ac->ac_g_ex.fe_len) {
|
|
|
|
i = j;
|
|
|
|
free -= freelen;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-08-17 14:02:17 +00:00
|
|
|
mb_find_extent(e4b, i, ac->ac_g_ex.fe_len, &ex);
|
2020-04-14 03:33:05 +00:00
|
|
|
if (WARN_ON(ex.fe_len <= 0))
|
|
|
|
break;
|
2008-02-10 06:10:04 +00:00
|
|
|
if (free < ex.fe_len) {
|
2024-01-04 14:20:40 +00:00
|
|
|
ext4_mark_group_bitmap_corrupted(sb, e4b->bd_group,
|
|
|
|
EXT4_GROUP_INFO_BBITMAP_CORRUPT);
|
2010-06-29 16:54:28 +00:00
|
|
|
ext4_grp_locked_error(sb, e4b->bd_group, 0, 0,
|
2011-09-09 22:48:51 +00:00
|
|
|
"%d free clusters as per "
|
2009-01-06 03:17:35 +00:00
|
|
|
"group info. But got %d blocks",
|
2008-02-10 06:10:04 +00:00
|
|
|
free, ex.fe_len);
|
2008-02-15 18:48:21 +00:00
|
|
|
/*
|
|
|
|
* The number of free blocks differs. This mostly
|
|
|
|
* indicate that the bitmap is corrupt. So exit
|
|
|
|
* without claiming the space.
|
|
|
|
*/
|
|
|
|
break;
|
2008-02-10 06:10:04 +00:00
|
|
|
}
|
2014-02-20 05:36:41 +00:00
|
|
|
ex.fe_logical = 0xDEADC0DE; /* debug value */
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_mb_measure_extent(ac, &ex, e4b);
|
|
|
|
|
|
|
|
i += ex.fe_len;
|
|
|
|
free -= ex.fe_len;
|
|
|
|
}
|
|
|
|
|
|
|
|
ext4_mb_check_limits(ac, e4b, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is a special case for storages like raid5
|
2010-07-27 15:56:06 +00:00
|
|
|
* we try to find stripe-aligned chunks for stripe-size-multiple requests
|
2008-01-29 05:19:52 +00:00
|
|
|
*/
|
2009-07-06 02:17:31 +00:00
|
|
|
static noinline_for_stack
|
|
|
|
void ext4_mb_scan_aligned(struct ext4_allocation_context *ac,
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_buddy *e4b)
|
|
|
|
{
|
|
|
|
struct super_block *sb = ac->ac_sb;
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
2012-02-20 22:54:06 +00:00
|
|
|
void *bitmap = e4b->bd_bitmap;
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_free_extent ex;
|
|
|
|
ext4_fsblk_t first_group_block;
|
|
|
|
ext4_fsblk_t a;
|
2023-06-03 15:03:12 +00:00
|
|
|
ext4_grpblk_t i, stripe;
|
2008-01-29 05:19:52 +00:00
|
|
|
int max;
|
|
|
|
|
|
|
|
BUG_ON(sbi->s_stripe == 0);
|
|
|
|
|
|
|
|
/* find first stripe-aligned block in group */
|
2010-03-04 04:53:39 +00:00
|
|
|
first_group_block = ext4_group_first_block_no(sb, e4b->bd_group);
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
a = first_group_block + sbi->s_stripe - 1;
|
|
|
|
do_div(a, sbi->s_stripe);
|
|
|
|
i = (a * sbi->s_stripe) - first_group_block;
|
|
|
|
|
2024-08-30 07:20:58 +00:00
|
|
|
stripe = EXT4_NUM_B2C(sbi, sbi->s_stripe);
|
2023-06-03 15:03:12 +00:00
|
|
|
i = EXT4_B2C(sbi, i);
|
2011-09-09 22:38:51 +00:00
|
|
|
while (i < EXT4_CLUSTERS_PER_GROUP(sb)) {
|
2008-01-29 05:19:52 +00:00
|
|
|
if (!mb_test_bit(i, bitmap)) {
|
2023-06-03 15:03:12 +00:00
|
|
|
max = mb_find_extent(e4b, i, stripe, &ex);
|
|
|
|
if (max >= stripe) {
|
2008-01-29 05:19:52 +00:00
|
|
|
ac->ac_found++;
|
2023-05-30 12:33:43 +00:00
|
|
|
ac->ac_cX_found[ac->ac_criteria]++;
|
2014-02-20 05:36:41 +00:00
|
|
|
ex.fe_logical = 0xDEADF00D; /* debug value */
|
2008-01-29 05:19:52 +00:00
|
|
|
ac->ac_b_ex = ex;
|
|
|
|
ext4_mb_use_best_found(ac, e4b);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2023-06-03 15:03:12 +00:00
|
|
|
i += stripe;
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-06-08 15:40:40 +00:00
|
|
|
/*
|
2020-05-20 06:40:35 +00:00
|
|
|
* This is also called BEFORE we load the buddy bitmap.
|
2015-06-08 15:40:40 +00:00
|
|
|
* Returns either 1 or 0 indicating that the group is either suitable
|
2020-05-20 06:40:35 +00:00
|
|
|
* for the allocation or not.
|
2015-06-08 15:40:40 +00:00
|
|
|
*/
|
2020-05-20 06:40:35 +00:00
|
|
|
static bool ext4_mb_good_group(struct ext4_allocation_context *ac,
|
2023-05-30 12:33:42 +00:00
|
|
|
ext4_group_t group, enum criteria cr)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
2020-05-20 06:40:35 +00:00
|
|
|
ext4_grpblk_t free, fragments;
|
2009-03-12 16:18:34 +00:00
|
|
|
int flex_size = ext4_flex_bg_size(EXT4_SB(ac->ac_sb));
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_group_info *grp = ext4_get_group_info(ac->ac_sb, group);
|
|
|
|
|
2023-05-30 12:33:50 +00:00
|
|
|
BUG_ON(cr < CR_POWER2_ALIGNED || cr >= EXT4_MB_NUM_CRS);
|
2010-05-16 19:00:00 +00:00
|
|
|
|
2023-08-01 14:31:55 +00:00
|
|
|
if (unlikely(!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp)))
|
2020-05-20 06:40:35 +00:00
|
|
|
return false;
|
2012-08-17 13:46:17 +00:00
|
|
|
|
2020-08-07 14:01:39 +00:00
|
|
|
free = grp->bb_free;
|
|
|
|
if (free == 0)
|
2020-05-20 06:40:35 +00:00
|
|
|
return false;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
fragments = grp->bb_fragments;
|
|
|
|
if (fragments == 0)
|
2020-05-20 06:40:35 +00:00
|
|
|
return false;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
switch (cr) {
|
2023-05-30 12:33:50 +00:00
|
|
|
case CR_POWER2_ALIGNED:
|
2008-01-29 05:19:52 +00:00
|
|
|
BUG_ON(ac->ac_2order == 0);
|
|
|
|
|
2009-03-12 16:18:34 +00:00
|
|
|
/* Avoid using the first bg of a flexgroup for data files */
|
|
|
|
if ((ac->ac_flags & EXT4_MB_HINT_DATA) &&
|
|
|
|
(flex_size >= EXT4_FLEX_SIZE_DIR_ALLOC_SCHEME) &&
|
|
|
|
((group % flex_size) == 0))
|
2020-05-20 06:40:35 +00:00
|
|
|
return false;
|
2009-03-12 16:18:34 +00:00
|
|
|
|
2020-08-07 14:01:39 +00:00
|
|
|
if (free < ac->ac_g_ex.fe_len)
|
|
|
|
return false;
|
|
|
|
|
2021-04-01 17:21:26 +00:00
|
|
|
if (ac->ac_2order >= MB_NUM_ORDERS(ac->ac_sb))
|
2020-05-20 06:40:35 +00:00
|
|
|
return true;
|
ext4: optimize mballoc for large allocations
The ext4 block allocator only maintains buddy bitmaps for chunks which
are less than or equal to one quarter of a block group. That is, for
a file aystem with a 1k blocksize, and where the number of blocks in a
block group is 8192 blocks, the largest chunk size tracked by buddy
bitmaps is 2048 blocks.
For a file system with a 4k blocksize, and where the number of blocks
in a block group is 32768 blocks, the largest chunk size tracked by
buddy bitmaps is 8192 blocks.
To work around this code, mballoc.c before this commit would truncate
allocation requests to the number of blocks in a block group minus 10.
Why 10? Aside from being a completely arbitrary number, it avoids
block allocation to be a power of two larger than 25% of the block
group. If you try to explicitly fallocate 50% of the block group
size, this will demonstrate the problem; the block allocation code
will scan the all of the blocks in the file system with cr==0 (since
the request is for a natural power of two), but then completely fail
for all blocks groups, since the buddy bitmaps don't track chunk sizes
of 50% of the block group.
To fix this, in these we use ext4_mb_complex_scan_group() instead of
ext4_mb_simple_scan_group().
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: Andreas Dilger <adilger@dilger.ca>
2013-02-04 20:08:40 +00:00
|
|
|
|
|
|
|
if (grp->bb_largest_free_order < ac->ac_2order)
|
2020-05-20 06:40:35 +00:00
|
|
|
return false;
|
ext4: optimize mballoc for large allocations
The ext4 block allocator only maintains buddy bitmaps for chunks which
are less than or equal to one quarter of a block group. That is, for
a file aystem with a 1k blocksize, and where the number of blocks in a
block group is 8192 blocks, the largest chunk size tracked by buddy
bitmaps is 2048 blocks.
For a file system with a 4k blocksize, and where the number of blocks
in a block group is 32768 blocks, the largest chunk size tracked by
buddy bitmaps is 8192 blocks.
To work around this code, mballoc.c before this commit would truncate
allocation requests to the number of blocks in a block group minus 10.
Why 10? Aside from being a completely arbitrary number, it avoids
block allocation to be a power of two larger than 25% of the block
group. If you try to explicitly fallocate 50% of the block group
size, this will demonstrate the problem; the block allocation code
will scan the all of the blocks in the file system with cr==0 (since
the request is for a natural power of two), but then completely fail
for all blocks groups, since the buddy bitmaps don't track chunk sizes
of 50% of the block group.
To fix this, in these we use ext4_mb_complex_scan_group() instead of
ext4_mb_simple_scan_group().
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: Andreas Dilger <adilger@dilger.ca>
2013-02-04 20:08:40 +00:00
|
|
|
|
2020-05-20 06:40:35 +00:00
|
|
|
return true;
|
2023-05-30 12:33:50 +00:00
|
|
|
case CR_GOAL_LEN_FAST:
|
|
|
|
case CR_BEST_AVAIL_LEN:
|
2008-01-29 05:19:52 +00:00
|
|
|
if ((free / fragments) >= ac->ac_g_ex.fe_len)
|
2020-05-20 06:40:35 +00:00
|
|
|
return true;
|
2008-01-29 05:19:52 +00:00
|
|
|
break;
|
2023-05-30 12:33:50 +00:00
|
|
|
case CR_GOAL_LEN_SLOW:
|
2008-01-29 05:19:52 +00:00
|
|
|
if (free >= ac->ac_g_ex.fe_len)
|
2020-05-20 06:40:35 +00:00
|
|
|
return true;
|
2008-01-29 05:19:52 +00:00
|
|
|
break;
|
2023-05-30 12:33:50 +00:00
|
|
|
case CR_ANY_FREE:
|
2020-05-20 06:40:35 +00:00
|
|
|
return true;
|
2008-01-29 05:19:52 +00:00
|
|
|
default:
|
|
|
|
BUG();
|
|
|
|
}
|
|
|
|
|
2020-05-20 06:40:35 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This could return negative error code if something goes wrong
|
|
|
|
* during ext4_mb_init_group(). This should not be called with
|
|
|
|
* ext4_lock_group() held.
|
2021-08-14 14:41:30 +00:00
|
|
|
*
|
|
|
|
* Note: because we are conditionally operating with the group lock in
|
|
|
|
* the EXT4_MB_STRICT_CHECK case, we need to fake out sparse in this
|
|
|
|
* function using __acquire and __release. This means we need to be
|
|
|
|
* super careful before messing with the error path handling via "goto
|
|
|
|
* out"!
|
2020-05-20 06:40:35 +00:00
|
|
|
*/
|
|
|
|
static int ext4_mb_good_group_nolock(struct ext4_allocation_context *ac,
|
2023-05-30 12:33:42 +00:00
|
|
|
ext4_group_t group, enum criteria cr)
|
2020-05-20 06:40:35 +00:00
|
|
|
{
|
|
|
|
struct ext4_group_info *grp = ext4_get_group_info(ac->ac_sb, group);
|
2020-05-20 06:40:36 +00:00
|
|
|
struct super_block *sb = ac->ac_sb;
|
2020-06-20 02:08:56 +00:00
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
2020-05-20 06:40:36 +00:00
|
|
|
bool should_lock = ac->ac_flags & EXT4_MB_STRICT_CHECK;
|
2020-05-20 06:40:35 +00:00
|
|
|
ext4_grpblk_t free;
|
|
|
|
int ret = 0;
|
|
|
|
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
if (!grp)
|
|
|
|
return -EFSCORRUPTED;
|
2021-04-01 17:21:25 +00:00
|
|
|
if (sbi->s_mb_stats)
|
|
|
|
atomic64_inc(&sbi->s_bal_cX_groups_considered[ac->ac_criteria]);
|
2021-08-14 14:41:30 +00:00
|
|
|
if (should_lock) {
|
2020-05-20 06:40:36 +00:00
|
|
|
ext4_lock_group(sb, group);
|
2021-08-14 14:41:30 +00:00
|
|
|
__release(ext4_group_lock_ptr(sb, group));
|
|
|
|
}
|
2020-05-20 06:40:35 +00:00
|
|
|
free = grp->bb_free;
|
|
|
|
if (free == 0)
|
|
|
|
goto out;
|
2023-06-30 08:59:27 +00:00
|
|
|
/*
|
|
|
|
* In all criterias except CR_ANY_FREE we try to avoid groups that
|
|
|
|
* can't possibly satisfy the full goal request due to insufficient
|
|
|
|
* free blocks.
|
|
|
|
*/
|
|
|
|
if (cr < CR_ANY_FREE && free < ac->ac_g_ex.fe_len)
|
2020-05-20 06:40:35 +00:00
|
|
|
goto out;
|
|
|
|
if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(grp)))
|
|
|
|
goto out;
|
2021-08-14 14:41:30 +00:00
|
|
|
if (should_lock) {
|
|
|
|
__acquire(ext4_group_lock_ptr(sb, group));
|
2020-05-20 06:40:36 +00:00
|
|
|
ext4_unlock_group(sb, group);
|
2021-08-14 14:41:30 +00:00
|
|
|
}
|
2020-05-20 06:40:35 +00:00
|
|
|
|
|
|
|
/* We only do this if the grp has never been initialized */
|
|
|
|
if (unlikely(EXT4_MB_GRP_NEED_INIT(grp))) {
|
2020-06-20 02:08:56 +00:00
|
|
|
struct ext4_group_desc *gdp =
|
|
|
|
ext4_get_group_desc(sb, group, NULL);
|
|
|
|
int ret;
|
|
|
|
|
2023-05-30 12:33:50 +00:00
|
|
|
/*
|
2024-04-24 06:19:03 +00:00
|
|
|
* CR_POWER2_ALIGNED/CR_GOAL_LEN_FAST is a very optimistic
|
2023-05-30 12:33:50 +00:00
|
|
|
* search to find large good chunks almost for free. If buddy
|
|
|
|
* data is not ready, then this optimization makes no sense. But
|
|
|
|
* we never skip the first block group in a flex_bg, since this
|
|
|
|
* gets used for metadata block allocation, and we want to make
|
|
|
|
* sure we locate metadata blocks in the first block group in
|
|
|
|
* the flex_bg if possible.
|
2020-06-20 02:08:56 +00:00
|
|
|
*/
|
2023-06-30 08:59:27 +00:00
|
|
|
if (!ext4_mb_cr_expensive(cr) &&
|
2020-06-20 02:08:56 +00:00
|
|
|
(!sbi->s_log_groups_per_flex ||
|
|
|
|
((group & ((1 << sbi->s_log_groups_per_flex) - 1)) != 0)) &&
|
|
|
|
!(ext4_has_group_desc_csum(sb) &&
|
|
|
|
(gdp->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT))))
|
|
|
|
return 0;
|
|
|
|
ret = ext4_mb_init_group(sb, group, GFP_NOFS);
|
2020-05-20 06:40:35 +00:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2021-08-14 14:41:30 +00:00
|
|
|
if (should_lock) {
|
2020-05-20 06:40:36 +00:00
|
|
|
ext4_lock_group(sb, group);
|
2021-08-14 14:41:30 +00:00
|
|
|
__release(ext4_group_lock_ptr(sb, group));
|
|
|
|
}
|
2020-05-20 06:40:35 +00:00
|
|
|
ret = ext4_mb_good_group(ac, group, cr);
|
|
|
|
out:
|
2021-08-14 14:41:30 +00:00
|
|
|
if (should_lock) {
|
|
|
|
__acquire(ext4_group_lock_ptr(sb, group));
|
2020-05-20 06:40:36 +00:00
|
|
|
ext4_unlock_group(sb, group);
|
2021-08-14 14:41:30 +00:00
|
|
|
}
|
2020-05-20 06:40:35 +00:00
|
|
|
return ret;
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
2020-04-21 07:54:07 +00:00
|
|
|
/*
|
|
|
|
* Start prefetching @nr block bitmaps starting at @group.
|
|
|
|
* Return the next group which needs to be prefetched.
|
|
|
|
*/
|
2020-07-17 04:14:40 +00:00
|
|
|
ext4_group_t ext4_mb_prefetch(struct super_block *sb, ext4_group_t group,
|
|
|
|
unsigned int nr, int *cnt)
|
2020-04-21 07:54:07 +00:00
|
|
|
{
|
|
|
|
ext4_group_t ngroups = ext4_get_groups_count(sb);
|
|
|
|
struct buffer_head *bh;
|
|
|
|
struct blk_plug plug;
|
|
|
|
|
|
|
|
blk_start_plug(&plug);
|
|
|
|
while (nr-- > 0) {
|
|
|
|
struct ext4_group_desc *gdp = ext4_get_group_desc(sb, group,
|
|
|
|
NULL);
|
|
|
|
struct ext4_group_info *grp = ext4_get_group_info(sb, group);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Prefetch block groups with free blocks; but don't
|
|
|
|
* bother if it is marked uninitialized on disk, since
|
|
|
|
* it won't require I/O to read. Also only try to
|
|
|
|
* prefetch once, so we avoid getblk() call, which can
|
|
|
|
* be expensive.
|
|
|
|
*/
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
if (gdp && grp && !EXT4_MB_GRP_TEST_AND_SET_READ(grp) &&
|
2020-04-21 07:54:07 +00:00
|
|
|
EXT4_MB_GRP_NEED_INIT(grp) &&
|
2023-05-30 12:33:46 +00:00
|
|
|
ext4_free_group_clusters(sb, gdp) > 0 ) {
|
2020-04-21 07:54:07 +00:00
|
|
|
bh = ext4_read_block_bitmap_nowait(sb, group, true);
|
|
|
|
if (bh && !IS_ERR(bh)) {
|
|
|
|
if (!buffer_uptodate(bh) && cnt)
|
|
|
|
(*cnt)++;
|
|
|
|
brelse(bh);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (++group >= ngroups)
|
|
|
|
group = 0;
|
|
|
|
}
|
|
|
|
blk_finish_plug(&plug);
|
|
|
|
return group;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Prefetching reads the block bitmap into the buffer cache; but we
|
|
|
|
* need to make sure that the buddy bitmap in the page cache has been
|
|
|
|
* initialized. Note that ext4_mb_init_group() will block if the I/O
|
|
|
|
* is not yet completed, or indeed if it was not initiated by
|
|
|
|
* ext4_mb_prefetch did not start the I/O.
|
|
|
|
*
|
|
|
|
* TODO: We should actually kick off the buddy bitmap setup in a work
|
|
|
|
* queue when the buffer I/O is completed, so that we don't block
|
|
|
|
* waiting for the block allocation bitmap read to finish when
|
|
|
|
* ext4_mb_prefetch_fini is called from ext4_mb_regular_allocator().
|
|
|
|
*/
|
2020-07-17 04:14:40 +00:00
|
|
|
void ext4_mb_prefetch_fini(struct super_block *sb, ext4_group_t group,
|
|
|
|
unsigned int nr)
|
2020-04-21 07:54:07 +00:00
|
|
|
{
|
2023-03-03 17:21:03 +00:00
|
|
|
struct ext4_group_desc *gdp;
|
|
|
|
struct ext4_group_info *grp;
|
2020-04-21 07:54:07 +00:00
|
|
|
|
2023-03-03 17:21:03 +00:00
|
|
|
while (nr-- > 0) {
|
2020-04-21 07:54:07 +00:00
|
|
|
if (!group)
|
|
|
|
group = ext4_get_groups_count(sb);
|
|
|
|
group--;
|
2023-03-03 17:21:03 +00:00
|
|
|
gdp = ext4_get_group_desc(sb, group, NULL);
|
2020-04-21 07:54:07 +00:00
|
|
|
grp = ext4_get_group_info(sb, group);
|
|
|
|
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
if (grp && gdp && EXT4_MB_GRP_NEED_INIT(grp) &&
|
2023-05-30 12:33:46 +00:00
|
|
|
ext4_free_group_clusters(sb, gdp) > 0) {
|
2020-04-21 07:54:07 +00:00
|
|
|
if (ext4_mb_init_group(sb, group, GFP_NOFS))
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-04-29 12:11:12 +00:00
|
|
|
static noinline_for_stack int
|
|
|
|
ext4_mb_regular_allocator(struct ext4_allocation_context *ac)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
2020-04-21 07:54:07 +00:00
|
|
|
ext4_group_t prefetch_grp = 0, ngroups, group, i;
|
2023-06-08 14:39:35 +00:00
|
|
|
enum criteria new_cr, cr = CR_GOAL_LEN_FAST;
|
2015-06-08 15:40:40 +00:00
|
|
|
int err = 0, first_err = 0;
|
2020-04-21 07:54:07 +00:00
|
|
|
unsigned int nr = 0, prefetch_ios = 0;
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_sb_info *sbi;
|
|
|
|
struct super_block *sb;
|
|
|
|
struct ext4_buddy e4b;
|
2020-08-17 07:36:06 +00:00
|
|
|
int lost;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
sb = ac->ac_sb;
|
|
|
|
sbi = EXT4_SB(sb);
|
2009-05-01 12:50:38 +00:00
|
|
|
ngroups = ext4_get_groups_count(sb);
|
ext4: limit block allocations for indirect-block files to < 2^32
Today, the ext4 allocator will happily allocate blocks past
2^32 for indirect-block files, which results in the block
numbers getting truncated, and corruption ensues.
This patch limits such allocations to < 2^32, and adds
BUG_ONs if we do get blocks larger than that.
This should address RH Bug 519471, ext4 bitmap allocator
must limit blocks to < 2^32
* ext4_find_goal() is modified to choose a goal < UINT_MAX,
so that our starting point is in an acceptable range.
* ext4_xattr_block_set() is modified such that the goal block
is < UINT_MAX, as above.
* ext4_mb_regular_allocator() is modified so that the group
search does not continue into groups which are too high
* ext4_mb_use_preallocated() has a check that we don't use
preallocated space which is too far out
* ext4_alloc_blocks() and ext4_xattr_block_set() add some BUG_ONs
No attempt has been made to limit inode locations to < 2^32,
so we may wind up with blocks far from their inodes. Doing
this much already will lead to some odd ENOSPC issues when the
"lower 32" gets full, and further restricting inodes could
make that even weirder.
For high inodes, choosing a goal of the original, % UINT_MAX,
may be a bit odd, but then we're in an odd situation anyway,
and I don't know of a better heuristic.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2009-09-16 18:45:10 +00:00
|
|
|
/* non-extent files are limited to low blocks/groups */
|
2010-05-17 02:00:00 +00:00
|
|
|
if (!(ext4_test_inode_flag(ac->ac_inode, EXT4_INODE_EXTENTS)))
|
ext4: limit block allocations for indirect-block files to < 2^32
Today, the ext4 allocator will happily allocate blocks past
2^32 for indirect-block files, which results in the block
numbers getting truncated, and corruption ensues.
This patch limits such allocations to < 2^32, and adds
BUG_ONs if we do get blocks larger than that.
This should address RH Bug 519471, ext4 bitmap allocator
must limit blocks to < 2^32
* ext4_find_goal() is modified to choose a goal < UINT_MAX,
so that our starting point is in an acceptable range.
* ext4_xattr_block_set() is modified such that the goal block
is < UINT_MAX, as above.
* ext4_mb_regular_allocator() is modified so that the group
search does not continue into groups which are too high
* ext4_mb_use_preallocated() has a check that we don't use
preallocated space which is too far out
* ext4_alloc_blocks() and ext4_xattr_block_set() add some BUG_ONs
No attempt has been made to limit inode locations to < 2^32,
so we may wind up with blocks far from their inodes. Doing
this much already will lead to some odd ENOSPC issues when the
"lower 32" gets full, and further restricting inodes could
make that even weirder.
For high inodes, choosing a goal of the original, % UINT_MAX,
may be a bit odd, but then we're in an odd situation anyway,
and I don't know of a better heuristic.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2009-09-16 18:45:10 +00:00
|
|
|
ngroups = sbi->s_blockfile_groups;
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
BUG_ON(ac->ac_status == AC_STATUS_FOUND);
|
|
|
|
|
|
|
|
/* first, try the goal */
|
|
|
|
err = ext4_mb_find_by_goal(ac, &e4b);
|
|
|
|
if (err || ac->ac_status == AC_STATUS_FOUND)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
if (unlikely(ac->ac_flags & EXT4_MB_HINT_GOAL_ONLY))
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/*
|
2020-08-07 14:01:23 +00:00
|
|
|
* ac->ac_2order is set only if the fe_len is a power of 2
|
2023-08-01 14:32:04 +00:00
|
|
|
* if ac->ac_2order is set we also set criteria to CR_POWER2_ALIGNED
|
|
|
|
* so that we try exact allocation using buddy.
|
2008-01-29 05:19:52 +00:00
|
|
|
*/
|
|
|
|
i = fls(ac->ac_g_ex.fe_len);
|
|
|
|
ac->ac_2order = 0;
|
|
|
|
/*
|
|
|
|
* We search using buddy data only if the order of the request
|
|
|
|
* is greater than equal to the sbi_s_mb_order2_reqs
|
2009-03-31 13:11:14 +00:00
|
|
|
* You can tune it via /sys/fs/ext4/<partition>/mb_order2_req
|
2017-02-10 05:50:56 +00:00
|
|
|
* We also support searching for power-of-two requests only for
|
|
|
|
* requests upto maximum buddy size we have constructed.
|
2008-01-29 05:19:52 +00:00
|
|
|
*/
|
2021-04-01 17:21:26 +00:00
|
|
|
if (i >= sbi->s_mb_order2_reqs && i <= MB_NUM_ORDERS(sb)) {
|
2023-08-01 14:31:58 +00:00
|
|
|
if (is_power_of_2(ac->ac_g_ex.fe_len))
|
2018-08-02 04:03:40 +00:00
|
|
|
ac->ac_2order = array_index_nospec(i - 1,
|
2021-04-01 17:21:26 +00:00
|
|
|
MB_NUM_ORDERS(sb));
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
2009-08-10 02:01:13 +00:00
|
|
|
/* if stream allocation is enabled, use global goal */
|
|
|
|
if (ac->ac_flags & EXT4_MB_STREAM_ALLOC) {
|
2008-01-29 05:19:52 +00:00
|
|
|
/* TBD: may be hot point */
|
|
|
|
spin_lock(&sbi->s_md_lock);
|
|
|
|
ac->ac_g_ex.fe_group = sbi->s_mb_last_group;
|
|
|
|
ac->ac_g_ex.fe_start = sbi->s_mb_last_start;
|
|
|
|
spin_unlock(&sbi->s_md_lock);
|
|
|
|
}
|
2009-08-10 02:01:13 +00:00
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
/*
|
2023-06-08 14:39:35 +00:00
|
|
|
* Let's just scan groups to find more-less suitable blocks We
|
|
|
|
* start with CR_GOAL_LEN_FAST, unless it is power of 2
|
|
|
|
* aligned, in which case let's do that faster approach first.
|
2008-01-29 05:19:52 +00:00
|
|
|
*/
|
2023-06-08 14:39:35 +00:00
|
|
|
if (ac->ac_2order)
|
|
|
|
cr = CR_POWER2_ALIGNED;
|
2008-01-29 05:19:52 +00:00
|
|
|
repeat:
|
2023-05-30 12:33:42 +00:00
|
|
|
for (; cr < EXT4_MB_NUM_CRS && ac->ac_status == AC_STATUS_CONTINUE; cr++) {
|
2008-01-29 05:19:52 +00:00
|
|
|
ac->ac_criteria = cr;
|
2008-07-11 23:27:31 +00:00
|
|
|
/*
|
|
|
|
* searching for the right group start
|
|
|
|
* from the goal value specified
|
|
|
|
*/
|
|
|
|
group = ac->ac_g_ex.fe_group;
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
ac->ac_groups_linear_remaining = sbi->s_mb_max_linear_groups;
|
2020-04-21 07:54:07 +00:00
|
|
|
prefetch_grp = group;
|
2024-04-24 06:19:00 +00:00
|
|
|
nr = 0;
|
2008-07-11 23:27:31 +00:00
|
|
|
|
2022-09-08 09:21:24 +00:00
|
|
|
for (i = 0, new_cr = cr; i < ngroups; i++,
|
|
|
|
ext4_mb_choose_next_group(ac, &new_cr, &group, ngroups)) {
|
|
|
|
int ret = 0;
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
|
2013-06-12 15:43:02 +00:00
|
|
|
cond_resched();
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
if (new_cr != cr) {
|
|
|
|
cr = new_cr;
|
|
|
|
goto repeat;
|
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2020-04-21 07:54:07 +00:00
|
|
|
/*
|
|
|
|
* Batch reads of the block allocation bitmaps
|
|
|
|
* to get multiple READs in flight; limit
|
2023-08-01 14:32:04 +00:00
|
|
|
* prefetching at inexpensive CR, otherwise mballoc
|
|
|
|
* can spend a lot of time loading imperfect groups
|
2020-04-21 07:54:07 +00:00
|
|
|
*/
|
|
|
|
if ((prefetch_grp == group) &&
|
2023-06-30 08:59:27 +00:00
|
|
|
(ext4_mb_cr_expensive(cr) ||
|
2020-04-21 07:54:07 +00:00
|
|
|
prefetch_ios < sbi->s_mb_prefetch_limit)) {
|
|
|
|
nr = sbi->s_mb_prefetch;
|
|
|
|
if (ext4_has_feature_flex_bg(sb)) {
|
ext4: avoid s_mb_prefetch to be zero in individual scenarios
Commit cfd732377221 ("ext4: add prefetching for block allocation
bitmaps") introduced block bitmap prefetch, and expects to read block
bitmaps of flex_bg through an IO. However, it seems to ignore the
value range of s_log_groups_per_flex. In the scenario where the value
of s_log_groups_per_flex is greater than 27, s_mb_prefetch or
s_mb_prefetch_limit will overflow, cause a divide zero exception.
In addition, the logic of calculating nr is also flawed, because the
size of flexbg is fixed during a single mount, but s_mb_prefetch can
be modified, which causes nr to fail to meet the value condition of
[1, flexbg_size].
To solve this problem, we need to set the upper limit of
s_mb_prefetch. Since we expect to load block bitmaps of a flex_bg
through an IO, we can consider determining a reasonable upper limit
among the IO limit parameters. After consideration, we chose
BLK_MAX_SEGMENT_SIZE. This is a good choice to solve divide zero
problem and avoiding performance degradation.
[ Some minor code simplifications to make the changes easy to follow -- TYT ]
Reported-by: Tosk Robot <tencent_os_robot@tencent.com>
Signed-off-by: Chunguang Xu <brookxu@tencent.com>
Reviewed-by: Samuel Liao <samuelliao@tencent.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/1607051143-24508-1-git-send-email-brookxu@tencent.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2020-12-04 03:05:43 +00:00
|
|
|
nr = 1 << sbi->s_log_groups_per_flex;
|
|
|
|
nr -= group & (nr - 1);
|
|
|
|
nr = min(nr, sbi->s_mb_prefetch);
|
2020-04-21 07:54:07 +00:00
|
|
|
}
|
|
|
|
prefetch_grp = ext4_mb_prefetch(sb, group,
|
|
|
|
nr, &prefetch_ios);
|
|
|
|
}
|
|
|
|
|
2010-05-16 19:00:00 +00:00
|
|
|
/* This now checks without needing the buddy page */
|
2020-05-20 06:40:35 +00:00
|
|
|
ret = ext4_mb_good_group_nolock(ac, group, cr);
|
2015-06-08 15:40:40 +00:00
|
|
|
if (ret <= 0) {
|
|
|
|
if (!first_err)
|
|
|
|
first_err = ret;
|
2008-01-29 05:19:52 +00:00
|
|
|
continue;
|
2015-06-08 15:40:40 +00:00
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
err = ext4_mb_load_buddy(sb, group, &e4b);
|
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
ext4_lock_group(sb, group);
|
2010-05-16 19:00:00 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We need to check again after locking the
|
|
|
|
* block group
|
|
|
|
*/
|
2015-06-08 15:40:40 +00:00
|
|
|
ret = ext4_mb_good_group(ac, group, cr);
|
2020-05-20 06:40:35 +00:00
|
|
|
if (ret == 0) {
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_unlock_group(sb, group);
|
2010-05-14 04:00:00 +00:00
|
|
|
ext4_mb_unload_buddy(&e4b);
|
2008-01-29 05:19:52 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
ac->ac_groups_scanned++;
|
2023-05-30 12:33:50 +00:00
|
|
|
if (cr == CR_POWER2_ALIGNED)
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_mb_simple_scan_group(ac, &e4b);
|
2023-12-15 11:19:50 +00:00
|
|
|
else {
|
2024-08-30 07:20:58 +00:00
|
|
|
bool is_stripe_aligned =
|
|
|
|
(sbi->s_stripe >=
|
|
|
|
sbi->s_cluster_ratio) &&
|
2023-12-15 11:19:50 +00:00
|
|
|
!(ac->ac_g_ex.fe_len %
|
2024-08-30 07:20:58 +00:00
|
|
|
EXT4_NUM_B2C(sbi, sbi->s_stripe));
|
2023-12-15 11:19:50 +00:00
|
|
|
|
|
|
|
if ((cr == CR_GOAL_LEN_FAST ||
|
|
|
|
cr == CR_BEST_AVAIL_LEN) &&
|
|
|
|
is_stripe_aligned)
|
|
|
|
ext4_mb_scan_aligned(ac, &e4b);
|
|
|
|
|
|
|
|
if (ac->ac_status == AC_STATUS_CONTINUE)
|
|
|
|
ext4_mb_complex_scan_group(ac, &e4b);
|
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
ext4_unlock_group(sb, group);
|
2010-05-14 04:00:00 +00:00
|
|
|
ext4_mb_unload_buddy(&e4b);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
if (ac->ac_status != AC_STATUS_CONTINUE)
|
|
|
|
break;
|
|
|
|
}
|
2021-04-01 17:21:25 +00:00
|
|
|
/* Processed all groups and haven't found blocks */
|
|
|
|
if (sbi->s_mb_stats && i == ngroups)
|
|
|
|
atomic64_inc(&sbi->s_bal_cX_failed[cr]);
|
2023-05-30 12:33:49 +00:00
|
|
|
|
2023-05-30 12:33:50 +00:00
|
|
|
if (i == ngroups && ac->ac_criteria == CR_BEST_AVAIL_LEN)
|
2023-05-30 12:33:49 +00:00
|
|
|
/* Reset goal length to original goal length before
|
2023-05-30 12:33:50 +00:00
|
|
|
* falling into CR_GOAL_LEN_SLOW */
|
2023-05-30 12:33:49 +00:00
|
|
|
ac->ac_g_ex.fe_len = ac->ac_orig_goal_len;
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (ac->ac_b_ex.fe_len > 0 && ac->ac_status != AC_STATUS_FOUND &&
|
|
|
|
!(ac->ac_flags & EXT4_MB_HINT_FIRST)) {
|
|
|
|
/*
|
|
|
|
* We've been searching too long. Let's try to allocate
|
|
|
|
* the best chunk we've found so far
|
|
|
|
*/
|
|
|
|
ext4_mb_try_best_found(ac, &e4b);
|
|
|
|
if (ac->ac_status != AC_STATUS_FOUND) {
|
|
|
|
/*
|
|
|
|
* Someone more lucky has already allocated it.
|
|
|
|
* The only thing we can do is just take first
|
|
|
|
* found block(s)
|
|
|
|
*/
|
2020-08-17 07:36:06 +00:00
|
|
|
lost = atomic_inc_return(&sbi->s_mb_lost_chunks);
|
|
|
|
mb_debug(sb, "lost chunk, group: %u, start: %d, len: %d, lost: %d\n",
|
2020-08-15 00:10:44 +00:00
|
|
|
ac->ac_b_ex.fe_group, ac->ac_b_ex.fe_start,
|
|
|
|
ac->ac_b_ex.fe_len, lost);
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
ac->ac_b_ex.fe_group = 0;
|
|
|
|
ac->ac_b_ex.fe_start = 0;
|
|
|
|
ac->ac_b_ex.fe_len = 0;
|
|
|
|
ac->ac_status = AC_STATUS_CONTINUE;
|
|
|
|
ac->ac_flags |= EXT4_MB_HINT_FIRST;
|
2023-05-30 12:33:50 +00:00
|
|
|
cr = CR_ANY_FREE;
|
2008-01-29 05:19:52 +00:00
|
|
|
goto repeat;
|
|
|
|
}
|
|
|
|
}
|
2021-04-01 17:21:25 +00:00
|
|
|
|
|
|
|
if (sbi->s_mb_stats && ac->ac_status == AC_STATUS_FOUND)
|
|
|
|
atomic64_inc(&sbi->s_bal_cX_hits[ac->ac_criteria]);
|
2008-01-29 05:19:52 +00:00
|
|
|
out:
|
2015-06-08 15:40:40 +00:00
|
|
|
if (!err && ac->ac_status != AC_STATUS_FOUND && first_err)
|
|
|
|
err = first_err;
|
2020-05-10 06:24:43 +00:00
|
|
|
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "Best len %d, origin len %d, ac_status %u, ac_flags 0x%x, cr %d ret %d\n",
|
2020-05-10 06:24:43 +00:00
|
|
|
ac->ac_b_ex.fe_len, ac->ac_o_ex.fe_len, ac->ac_status,
|
|
|
|
ac->ac_flags, cr, err);
|
2020-04-21 07:54:07 +00:00
|
|
|
|
|
|
|
if (nr)
|
|
|
|
ext4_mb_prefetch_fini(sb, prefetch_grp, nr);
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void *ext4_mb_seq_groups_start(struct seq_file *seq, loff_t *pos)
|
|
|
|
{
|
2022-01-22 06:14:23 +00:00
|
|
|
struct super_block *sb = pde_data(file_inode(seq->file));
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_group_t group;
|
|
|
|
|
2009-05-01 12:50:38 +00:00
|
|
|
if (*pos < 0 || *pos >= ext4_get_groups_count(sb))
|
2008-01-29 05:19:52 +00:00
|
|
|
return NULL;
|
|
|
|
group = *pos + 1;
|
2009-01-06 03:18:16 +00:00
|
|
|
return (void *) ((unsigned long) group);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void *ext4_mb_seq_groups_next(struct seq_file *seq, void *v, loff_t *pos)
|
|
|
|
{
|
2022-01-22 06:14:23 +00:00
|
|
|
struct super_block *sb = pde_data(file_inode(seq->file));
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_group_t group;
|
|
|
|
|
|
|
|
++*pos;
|
2009-05-01 12:50:38 +00:00
|
|
|
if (*pos < 0 || *pos >= ext4_get_groups_count(sb))
|
2008-01-29 05:19:52 +00:00
|
|
|
return NULL;
|
|
|
|
group = *pos + 1;
|
2009-01-06 03:18:16 +00:00
|
|
|
return (void *) ((unsigned long) group);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int ext4_mb_seq_groups_show(struct seq_file *seq, void *v)
|
|
|
|
{
|
2022-01-22 06:14:23 +00:00
|
|
|
struct super_block *sb = pde_data(file_inode(seq->file));
|
2009-01-06 03:18:16 +00:00
|
|
|
ext4_group_t group = (ext4_group_t) ((unsigned long) v);
|
2024-01-18 04:25:56 +00:00
|
|
|
int i, err;
|
2024-01-18 04:25:57 +00:00
|
|
|
char nbuf[16];
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_buddy e4b;
|
2012-06-30 23:10:57 +00:00
|
|
|
struct ext4_group_info *grinfo;
|
2017-08-06 01:57:46 +00:00
|
|
|
unsigned char blocksize_bits = min_t(unsigned char,
|
|
|
|
sb->s_blocksize_bits,
|
|
|
|
EXT4_MAX_BLOCK_LOG_SIZE);
|
2008-01-29 05:19:52 +00:00
|
|
|
struct sg {
|
|
|
|
struct ext4_group_info info;
|
2017-08-14 12:29:18 +00:00
|
|
|
ext4_grpblk_t counters[EXT4_MAX_BLOCK_LOG_SIZE + 2];
|
2008-01-29 05:19:52 +00:00
|
|
|
} sg;
|
|
|
|
|
|
|
|
group--;
|
|
|
|
if (group == 0)
|
2015-06-15 04:32:58 +00:00
|
|
|
seq_puts(seq, "#group: free frags first ["
|
|
|
|
" 2^0 2^1 2^2 2^3 2^4 2^5 2^6 "
|
2016-02-12 05:17:16 +00:00
|
|
|
" 2^7 2^8 2^9 2^10 2^11 2^12 2^13 ]\n");
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2017-08-14 12:29:18 +00:00
|
|
|
i = (blocksize_bits + 2) * sizeof(sg.info.bb_counters[0]) +
|
|
|
|
sizeof(struct ext4_group_info);
|
|
|
|
|
2012-06-30 23:10:57 +00:00
|
|
|
grinfo = ext4_get_group_info(sb, group);
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
if (!grinfo)
|
|
|
|
return 0;
|
2012-06-30 23:10:57 +00:00
|
|
|
/* Load the group info in memory only if not already loaded. */
|
|
|
|
if (unlikely(EXT4_MB_GRP_NEED_INIT(grinfo))) {
|
|
|
|
err = ext4_mb_load_buddy(sb, group, &e4b);
|
|
|
|
if (err) {
|
2024-01-18 04:25:57 +00:00
|
|
|
seq_printf(seq, "#%-5u: %s\n", group, ext4_decode_error(NULL, err, nbuf));
|
2012-06-30 23:10:57 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2024-01-18 04:25:56 +00:00
|
|
|
ext4_mb_unload_buddy(&e4b);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2012-06-30 23:10:57 +00:00
|
|
|
|
2024-01-18 04:25:56 +00:00
|
|
|
/*
|
|
|
|
* We care only about free space counters in the group info and
|
|
|
|
* these are safe to access even after the buddy has been unloaded
|
|
|
|
*/
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
memcpy(&sg, grinfo, i);
|
2009-01-06 03:18:16 +00:00
|
|
|
seq_printf(seq, "#%-5u: %-5u %-5u %-5u [", group, sg.info.bb_free,
|
2008-01-29 05:19:52 +00:00
|
|
|
sg.info.bb_fragments, sg.info.bb_first_free);
|
|
|
|
for (i = 0; i <= 13; i++)
|
2017-08-06 01:57:46 +00:00
|
|
|
seq_printf(seq, " %-5u", i <= blocksize_bits + 1 ?
|
2008-01-29 05:19:52 +00:00
|
|
|
sg.info.bb_counters[i] : 0);
|
2024-01-19 06:11:54 +00:00
|
|
|
seq_puts(seq, " ]");
|
|
|
|
if (EXT4_MB_GRP_BBITMAP_CORRUPT(&sg.info))
|
|
|
|
seq_puts(seq, " Block bitmap corrupted!");
|
2024-07-13 15:10:24 +00:00
|
|
|
seq_putc(seq, '\n');
|
2008-01-29 05:19:52 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ext4_mb_seq_groups_stop(struct seq_file *seq, void *v)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2018-04-11 09:37:23 +00:00
|
|
|
const struct seq_operations ext4_mb_seq_groups_ops = {
|
2008-01-29 05:19:52 +00:00
|
|
|
.start = ext4_mb_seq_groups_start,
|
|
|
|
.next = ext4_mb_seq_groups_next,
|
|
|
|
.stop = ext4_mb_seq_groups_stop,
|
|
|
|
.show = ext4_mb_seq_groups_show,
|
|
|
|
};
|
|
|
|
|
2021-04-01 17:21:25 +00:00
|
|
|
int ext4_seq_mb_stats_show(struct seq_file *seq, void *offset)
|
|
|
|
{
|
2022-04-01 08:13:21 +00:00
|
|
|
struct super_block *sb = seq->private;
|
2021-04-01 17:21:25 +00:00
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
|
|
|
|
|
|
|
seq_puts(seq, "mballoc:\n");
|
|
|
|
if (!sbi->s_mb_stats) {
|
|
|
|
seq_puts(seq, "\tmb stats collection turned off.\n");
|
2023-05-30 12:33:50 +00:00
|
|
|
seq_puts(
|
|
|
|
seq,
|
|
|
|
"\tTo enable, please write \"1\" to sysfs file mb_stats.\n");
|
2021-04-01 17:21:25 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
seq_printf(seq, "\treqs: %u\n", atomic_read(&sbi->s_bal_reqs));
|
|
|
|
seq_printf(seq, "\tsuccess: %u\n", atomic_read(&sbi->s_bal_success));
|
|
|
|
|
2023-05-30 12:33:50 +00:00
|
|
|
seq_printf(seq, "\tgroups_scanned: %u\n",
|
|
|
|
atomic_read(&sbi->s_bal_groups_scanned));
|
|
|
|
|
|
|
|
/* CR_POWER2_ALIGNED stats */
|
|
|
|
seq_puts(seq, "\tcr_p2_aligned_stats:\n");
|
|
|
|
seq_printf(seq, "\t\thits: %llu\n",
|
|
|
|
atomic64_read(&sbi->s_bal_cX_hits[CR_POWER2_ALIGNED]));
|
|
|
|
seq_printf(
|
|
|
|
seq, "\t\tgroups_considered: %llu\n",
|
|
|
|
atomic64_read(
|
|
|
|
&sbi->s_bal_cX_groups_considered[CR_POWER2_ALIGNED]));
|
|
|
|
seq_printf(seq, "\t\textents_scanned: %u\n",
|
|
|
|
atomic_read(&sbi->s_bal_cX_ex_scanned[CR_POWER2_ALIGNED]));
|
2021-04-01 17:21:25 +00:00
|
|
|
seq_printf(seq, "\t\tuseless_loops: %llu\n",
|
2023-05-30 12:33:50 +00:00
|
|
|
atomic64_read(&sbi->s_bal_cX_failed[CR_POWER2_ALIGNED]));
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
seq_printf(seq, "\t\tbad_suggestions: %u\n",
|
2023-05-30 12:33:50 +00:00
|
|
|
atomic_read(&sbi->s_bal_p2_aligned_bad_suggestions));
|
2021-04-01 17:21:25 +00:00
|
|
|
|
2023-05-30 12:33:50 +00:00
|
|
|
/* CR_GOAL_LEN_FAST stats */
|
|
|
|
seq_puts(seq, "\tcr_goal_fast_stats:\n");
|
|
|
|
seq_printf(seq, "\t\thits: %llu\n",
|
|
|
|
atomic64_read(&sbi->s_bal_cX_hits[CR_GOAL_LEN_FAST]));
|
2021-04-01 17:21:25 +00:00
|
|
|
seq_printf(seq, "\t\tgroups_considered: %llu\n",
|
2023-05-30 12:33:50 +00:00
|
|
|
atomic64_read(
|
|
|
|
&sbi->s_bal_cX_groups_considered[CR_GOAL_LEN_FAST]));
|
|
|
|
seq_printf(seq, "\t\textents_scanned: %u\n",
|
|
|
|
atomic_read(&sbi->s_bal_cX_ex_scanned[CR_GOAL_LEN_FAST]));
|
2021-04-01 17:21:25 +00:00
|
|
|
seq_printf(seq, "\t\tuseless_loops: %llu\n",
|
2023-05-30 12:33:50 +00:00
|
|
|
atomic64_read(&sbi->s_bal_cX_failed[CR_GOAL_LEN_FAST]));
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
seq_printf(seq, "\t\tbad_suggestions: %u\n",
|
2023-05-30 12:33:50 +00:00
|
|
|
atomic_read(&sbi->s_bal_goal_fast_bad_suggestions));
|
|
|
|
|
|
|
|
/* CR_BEST_AVAIL_LEN stats */
|
|
|
|
seq_puts(seq, "\tcr_best_avail_stats:\n");
|
|
|
|
seq_printf(seq, "\t\thits: %llu\n",
|
|
|
|
atomic64_read(&sbi->s_bal_cX_hits[CR_BEST_AVAIL_LEN]));
|
|
|
|
seq_printf(
|
|
|
|
seq, "\t\tgroups_considered: %llu\n",
|
|
|
|
atomic64_read(
|
|
|
|
&sbi->s_bal_cX_groups_considered[CR_BEST_AVAIL_LEN]));
|
|
|
|
seq_printf(seq, "\t\textents_scanned: %u\n",
|
|
|
|
atomic_read(&sbi->s_bal_cX_ex_scanned[CR_BEST_AVAIL_LEN]));
|
2023-05-30 12:33:49 +00:00
|
|
|
seq_printf(seq, "\t\tuseless_loops: %llu\n",
|
2023-05-30 12:33:50 +00:00
|
|
|
atomic64_read(&sbi->s_bal_cX_failed[CR_BEST_AVAIL_LEN]));
|
2023-05-30 12:33:49 +00:00
|
|
|
seq_printf(seq, "\t\tbad_suggestions: %u\n",
|
2023-05-30 12:33:50 +00:00
|
|
|
atomic_read(&sbi->s_bal_best_avail_bad_suggestions));
|
2023-05-30 12:33:49 +00:00
|
|
|
|
2023-05-30 12:33:50 +00:00
|
|
|
/* CR_GOAL_LEN_SLOW stats */
|
|
|
|
seq_puts(seq, "\tcr_goal_slow_stats:\n");
|
|
|
|
seq_printf(seq, "\t\thits: %llu\n",
|
|
|
|
atomic64_read(&sbi->s_bal_cX_hits[CR_GOAL_LEN_SLOW]));
|
2021-04-01 17:21:25 +00:00
|
|
|
seq_printf(seq, "\t\tgroups_considered: %llu\n",
|
2023-05-30 12:33:50 +00:00
|
|
|
atomic64_read(
|
|
|
|
&sbi->s_bal_cX_groups_considered[CR_GOAL_LEN_SLOW]));
|
|
|
|
seq_printf(seq, "\t\textents_scanned: %u\n",
|
|
|
|
atomic_read(&sbi->s_bal_cX_ex_scanned[CR_GOAL_LEN_SLOW]));
|
2021-04-01 17:21:25 +00:00
|
|
|
seq_printf(seq, "\t\tuseless_loops: %llu\n",
|
2023-05-30 12:33:50 +00:00
|
|
|
atomic64_read(&sbi->s_bal_cX_failed[CR_GOAL_LEN_SLOW]));
|
|
|
|
|
|
|
|
/* CR_ANY_FREE stats */
|
|
|
|
seq_puts(seq, "\tcr_any_free_stats:\n");
|
|
|
|
seq_printf(seq, "\t\thits: %llu\n",
|
|
|
|
atomic64_read(&sbi->s_bal_cX_hits[CR_ANY_FREE]));
|
|
|
|
seq_printf(
|
|
|
|
seq, "\t\tgroups_considered: %llu\n",
|
|
|
|
atomic64_read(&sbi->s_bal_cX_groups_considered[CR_ANY_FREE]));
|
|
|
|
seq_printf(seq, "\t\textents_scanned: %u\n",
|
|
|
|
atomic_read(&sbi->s_bal_cX_ex_scanned[CR_ANY_FREE]));
|
2021-04-01 17:21:25 +00:00
|
|
|
seq_printf(seq, "\t\tuseless_loops: %llu\n",
|
2023-05-30 12:33:50 +00:00
|
|
|
atomic64_read(&sbi->s_bal_cX_failed[CR_ANY_FREE]));
|
|
|
|
|
|
|
|
/* Aggregates */
|
|
|
|
seq_printf(seq, "\textents_scanned: %u\n",
|
|
|
|
atomic_read(&sbi->s_bal_ex_scanned));
|
2021-04-01 17:21:25 +00:00
|
|
|
seq_printf(seq, "\t\tgoal_hits: %u\n", atomic_read(&sbi->s_bal_goals));
|
2023-05-30 12:33:50 +00:00
|
|
|
seq_printf(seq, "\t\tlen_goal_hits: %u\n",
|
|
|
|
atomic_read(&sbi->s_bal_len_goals));
|
2021-04-01 17:21:25 +00:00
|
|
|
seq_printf(seq, "\t\t2^n_hits: %u\n", atomic_read(&sbi->s_bal_2orders));
|
|
|
|
seq_printf(seq, "\t\tbreaks: %u\n", atomic_read(&sbi->s_bal_breaks));
|
|
|
|
seq_printf(seq, "\t\tlost: %u\n", atomic_read(&sbi->s_mb_lost_chunks));
|
|
|
|
seq_printf(seq, "\tbuddies_generated: %u/%u\n",
|
|
|
|
atomic_read(&sbi->s_mb_buddies_generated),
|
|
|
|
ext4_get_groups_count(sb));
|
|
|
|
seq_printf(seq, "\tbuddies_time_used: %llu\n",
|
|
|
|
atomic64_read(&sbi->s_mb_generation_time));
|
|
|
|
seq_printf(seq, "\tpreallocated: %u\n",
|
|
|
|
atomic_read(&sbi->s_mb_preallocated));
|
2023-05-30 12:33:50 +00:00
|
|
|
seq_printf(seq, "\tdiscarded: %u\n", atomic_read(&sbi->s_mb_discarded));
|
2021-04-01 17:21:25 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-04-01 17:21:28 +00:00
|
|
|
static void *ext4_mb_seq_structs_summary_start(struct seq_file *seq, loff_t *pos)
|
|
|
|
{
|
2022-01-22 06:14:23 +00:00
|
|
|
struct super_block *sb = pde_data(file_inode(seq->file));
|
2021-04-01 17:21:28 +00:00
|
|
|
unsigned long position;
|
|
|
|
|
2022-09-08 09:21:28 +00:00
|
|
|
if (*pos < 0 || *pos >= 2*MB_NUM_ORDERS(sb))
|
2021-04-01 17:21:28 +00:00
|
|
|
return NULL;
|
|
|
|
position = *pos + 1;
|
|
|
|
return (void *) ((unsigned long) position);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void *ext4_mb_seq_structs_summary_next(struct seq_file *seq, void *v, loff_t *pos)
|
|
|
|
{
|
2022-01-22 06:14:23 +00:00
|
|
|
struct super_block *sb = pde_data(file_inode(seq->file));
|
2021-04-01 17:21:28 +00:00
|
|
|
unsigned long position;
|
|
|
|
|
|
|
|
++*pos;
|
2022-09-08 09:21:28 +00:00
|
|
|
if (*pos < 0 || *pos >= 2*MB_NUM_ORDERS(sb))
|
2021-04-01 17:21:28 +00:00
|
|
|
return NULL;
|
|
|
|
position = *pos + 1;
|
|
|
|
return (void *) ((unsigned long) position);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int ext4_mb_seq_structs_summary_show(struct seq_file *seq, void *v)
|
|
|
|
{
|
2022-01-22 06:14:23 +00:00
|
|
|
struct super_block *sb = pde_data(file_inode(seq->file));
|
2021-04-01 17:21:28 +00:00
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
|
|
|
unsigned long position = ((unsigned long) v);
|
|
|
|
struct ext4_group_info *grp;
|
2022-09-08 09:21:28 +00:00
|
|
|
unsigned int count;
|
2021-04-01 17:21:28 +00:00
|
|
|
|
|
|
|
position--;
|
|
|
|
if (position >= MB_NUM_ORDERS(sb)) {
|
2022-09-08 09:21:28 +00:00
|
|
|
position -= MB_NUM_ORDERS(sb);
|
|
|
|
if (position == 0)
|
|
|
|
seq_puts(seq, "avg_fragment_size_lists:\n");
|
2021-04-01 17:21:28 +00:00
|
|
|
|
2022-09-08 09:21:28 +00:00
|
|
|
count = 0;
|
|
|
|
read_lock(&sbi->s_mb_avg_fragment_size_locks[position]);
|
|
|
|
list_for_each_entry(grp, &sbi->s_mb_avg_fragment_size[position],
|
|
|
|
bb_avg_fragment_size_node)
|
|
|
|
count++;
|
|
|
|
read_unlock(&sbi->s_mb_avg_fragment_size_locks[position]);
|
|
|
|
seq_printf(seq, "\tlist_order_%u_groups: %u\n",
|
|
|
|
(unsigned int)position, count);
|
2021-04-01 17:21:28 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (position == 0) {
|
|
|
|
seq_printf(seq, "optimize_scan: %d\n",
|
|
|
|
test_opt2(sb, MB_OPTIMIZE_SCAN) ? 1 : 0);
|
|
|
|
seq_puts(seq, "max_free_order_lists:\n");
|
|
|
|
}
|
|
|
|
count = 0;
|
2022-09-08 09:21:28 +00:00
|
|
|
read_lock(&sbi->s_mb_largest_free_orders_locks[position]);
|
2021-04-01 17:21:28 +00:00
|
|
|
list_for_each_entry(grp, &sbi->s_mb_largest_free_orders[position],
|
|
|
|
bb_largest_free_order_node)
|
|
|
|
count++;
|
2022-09-08 09:21:28 +00:00
|
|
|
read_unlock(&sbi->s_mb_largest_free_orders_locks[position]);
|
2021-04-01 17:21:28 +00:00
|
|
|
seq_printf(seq, "\tlist_order_%u_groups: %u\n",
|
|
|
|
(unsigned int)position, count);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ext4_mb_seq_structs_summary_stop(struct seq_file *seq, void *v)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
const struct seq_operations ext4_mb_seq_structs_summary_ops = {
|
|
|
|
.start = ext4_mb_seq_structs_summary_start,
|
|
|
|
.next = ext4_mb_seq_structs_summary_next,
|
|
|
|
.stop = ext4_mb_seq_structs_summary_stop,
|
|
|
|
.show = ext4_mb_seq_structs_summary_show,
|
|
|
|
};
|
|
|
|
|
2010-10-28 01:29:12 +00:00
|
|
|
static struct kmem_cache *get_groupinfo_cache(int blocksize_bits)
|
|
|
|
{
|
|
|
|
int cache_index = blocksize_bits - EXT4_MIN_BLOCK_LOG_SIZE;
|
|
|
|
struct kmem_cache *cachep = ext4_groupinfo_caches[cache_index];
|
|
|
|
|
|
|
|
BUG_ON(!cachep);
|
|
|
|
return cachep;
|
|
|
|
}
|
2008-07-11 23:27:31 +00:00
|
|
|
|
2012-09-05 05:31:50 +00:00
|
|
|
/*
|
|
|
|
* Allocate the top-level s_group_info array for the specified number
|
|
|
|
* of groups
|
|
|
|
*/
|
|
|
|
int ext4_mb_alloc_groupinfo(struct super_block *sb, ext4_group_t ngroups)
|
|
|
|
{
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
|
|
|
unsigned size;
|
2020-02-19 03:08:50 +00:00
|
|
|
struct ext4_group_info ***old_groupinfo, ***new_groupinfo;
|
2012-09-05 05:31:50 +00:00
|
|
|
|
|
|
|
size = (ngroups + EXT4_DESC_PER_BLOCK(sb) - 1) >>
|
|
|
|
EXT4_DESC_PER_BLOCK_BITS(sb);
|
|
|
|
if (size <= sbi->s_group_info_size)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
size = roundup_pow_of_two(sizeof(*sbi->s_group_info) * size);
|
2017-05-08 22:57:09 +00:00
|
|
|
new_groupinfo = kvzalloc(size, GFP_KERNEL);
|
2012-09-05 05:31:50 +00:00
|
|
|
if (!new_groupinfo) {
|
|
|
|
ext4_msg(sb, KERN_ERR, "can't allocate buddy meta group");
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
2020-02-19 03:08:50 +00:00
|
|
|
rcu_read_lock();
|
|
|
|
old_groupinfo = rcu_dereference(sbi->s_group_info);
|
|
|
|
if (old_groupinfo)
|
|
|
|
memcpy(new_groupinfo, old_groupinfo,
|
2012-09-05 05:31:50 +00:00
|
|
|
sbi->s_group_info_size * sizeof(*sbi->s_group_info));
|
2020-02-19 03:08:50 +00:00
|
|
|
rcu_read_unlock();
|
|
|
|
rcu_assign_pointer(sbi->s_group_info, new_groupinfo);
|
2012-09-05 05:31:50 +00:00
|
|
|
sbi->s_group_info_size = size / sizeof(*sbi->s_group_info);
|
2020-02-19 03:08:50 +00:00
|
|
|
if (old_groupinfo)
|
|
|
|
ext4_kvfree_array_rcu(old_groupinfo);
|
2021-04-09 04:20:35 +00:00
|
|
|
ext4_debug("allocated s_groupinfo array for %d meta_bg's\n",
|
2012-09-05 05:31:50 +00:00
|
|
|
sbi->s_group_info_size);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-07-11 23:27:31 +00:00
|
|
|
/* Create and initialize ext4_group_info data for the given group. */
|
2009-01-06 02:36:19 +00:00
|
|
|
int ext4_mb_add_groupinfo(struct super_block *sb, ext4_group_t group,
|
2008-07-11 23:27:31 +00:00
|
|
|
struct ext4_group_desc *desc)
|
|
|
|
{
|
2010-10-28 01:29:12 +00:00
|
|
|
int i;
|
2008-07-11 23:27:31 +00:00
|
|
|
int metalen = 0;
|
2020-02-19 03:08:50 +00:00
|
|
|
int idx = group >> EXT4_DESC_PER_BLOCK_BITS(sb);
|
2008-07-11 23:27:31 +00:00
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
|
|
|
struct ext4_group_info **meta_group_info;
|
2010-10-28 01:29:12 +00:00
|
|
|
struct kmem_cache *cachep = get_groupinfo_cache(sb->s_blocksize_bits);
|
2008-07-11 23:27:31 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* First check if this group is the first of a reserved block.
|
|
|
|
* If it's true, we have to allocate a new table of pointers
|
|
|
|
* to ext4_group_info structures
|
|
|
|
*/
|
|
|
|
if (group % EXT4_DESC_PER_BLOCK(sb) == 0) {
|
|
|
|
metalen = sizeof(*meta_group_info) <<
|
|
|
|
EXT4_DESC_PER_BLOCK_BITS(sb);
|
2014-11-25 18:08:04 +00:00
|
|
|
meta_group_info = kmalloc(metalen, GFP_NOFS);
|
2008-07-11 23:27:31 +00:00
|
|
|
if (meta_group_info == NULL) {
|
2012-03-20 03:09:43 +00:00
|
|
|
ext4_msg(sb, KERN_ERR, "can't allocate mem "
|
2011-08-01 21:41:35 +00:00
|
|
|
"for a buddy group");
|
2023-03-03 17:21:15 +00:00
|
|
|
return -ENOMEM;
|
2008-07-11 23:27:31 +00:00
|
|
|
}
|
2020-02-19 03:08:50 +00:00
|
|
|
rcu_read_lock();
|
|
|
|
rcu_dereference(sbi->s_group_info)[idx] = meta_group_info;
|
|
|
|
rcu_read_unlock();
|
2008-07-11 23:27:31 +00:00
|
|
|
}
|
|
|
|
|
2020-02-19 03:08:50 +00:00
|
|
|
meta_group_info = sbi_array_rcu_deref(sbi, s_group_info, idx);
|
2008-07-11 23:27:31 +00:00
|
|
|
i = group & (EXT4_DESC_PER_BLOCK(sb) - 1);
|
|
|
|
|
2014-11-25 18:08:04 +00:00
|
|
|
meta_group_info[i] = kmem_cache_zalloc(cachep, GFP_NOFS);
|
2008-07-11 23:27:31 +00:00
|
|
|
if (meta_group_info[i] == NULL) {
|
2012-03-20 03:09:43 +00:00
|
|
|
ext4_msg(sb, KERN_ERR, "can't allocate buddy mem");
|
2008-07-11 23:27:31 +00:00
|
|
|
goto exit_group_info;
|
|
|
|
}
|
|
|
|
set_bit(EXT4_GROUP_INFO_NEED_INIT_BIT,
|
|
|
|
&(meta_group_info[i]->bb_state));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* initialize bb_free to be able to skip
|
|
|
|
* empty groups without initialization
|
|
|
|
*/
|
2018-06-14 04:58:00 +00:00
|
|
|
if (ext4_has_group_desc_csum(sb) &&
|
|
|
|
(desc->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT))) {
|
2008-07-11 23:27:31 +00:00
|
|
|
meta_group_info[i]->bb_free =
|
2011-09-09 23:12:51 +00:00
|
|
|
ext4_free_clusters_after_init(sb, group, desc);
|
2008-07-11 23:27:31 +00:00
|
|
|
} else {
|
|
|
|
meta_group_info[i]->bb_free =
|
2011-09-09 23:08:51 +00:00
|
|
|
ext4_free_group_clusters(sb, desc);
|
2008-07-11 23:27:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&meta_group_info[i]->bb_prealloc_list);
|
2009-01-06 02:36:19 +00:00
|
|
|
init_rwsem(&meta_group_info[i]->alloc_sem);
|
2010-03-05 03:25:21 +00:00
|
|
|
meta_group_info[i]->bb_free_root = RB_ROOT;
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
INIT_LIST_HEAD(&meta_group_info[i]->bb_largest_free_order_node);
|
2022-09-08 09:21:28 +00:00
|
|
|
INIT_LIST_HEAD(&meta_group_info[i]->bb_avg_fragment_size_node);
|
2010-05-16 19:00:00 +00:00
|
|
|
meta_group_info[i]->bb_largest_free_order = -1; /* uninit */
|
2022-09-08 09:21:28 +00:00
|
|
|
meta_group_info[i]->bb_avg_fragment_size_order = -1; /* uninit */
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
meta_group_info[i]->bb_group = group;
|
2008-07-11 23:27:31 +00:00
|
|
|
|
2020-05-10 06:24:48 +00:00
|
|
|
mb_group_bb_bitmap_alloc(sb, meta_group_info[i], group);
|
2008-07-11 23:27:31 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
exit_group_info:
|
|
|
|
/* If a meta_group_info table has been allocated, release it now */
|
2011-07-11 22:42:42 +00:00
|
|
|
if (group % EXT4_DESC_PER_BLOCK(sb) == 0) {
|
2020-02-19 03:08:50 +00:00
|
|
|
struct ext4_group_info ***group_info;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
group_info = rcu_dereference(sbi->s_group_info);
|
|
|
|
kfree(group_info[idx]);
|
|
|
|
group_info[idx] = NULL;
|
|
|
|
rcu_read_unlock();
|
2011-07-11 22:42:42 +00:00
|
|
|
}
|
2008-07-11 23:27:31 +00:00
|
|
|
return -ENOMEM;
|
|
|
|
} /* ext4_mb_add_groupinfo */
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
static int ext4_mb_init_backend(struct super_block *sb)
|
|
|
|
{
|
2009-05-01 12:50:38 +00:00
|
|
|
ext4_group_t ngroups = ext4_get_groups_count(sb);
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_group_t i;
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
2012-09-05 05:31:50 +00:00
|
|
|
int err;
|
2008-07-11 23:27:31 +00:00
|
|
|
struct ext4_group_desc *desc;
|
2020-02-19 03:08:50 +00:00
|
|
|
struct ext4_group_info ***group_info;
|
2010-10-28 01:29:12 +00:00
|
|
|
struct kmem_cache *cachep;
|
2008-07-11 23:27:31 +00:00
|
|
|
|
2012-09-05 05:31:50 +00:00
|
|
|
err = ext4_mb_alloc_groupinfo(sb, ngroups);
|
|
|
|
if (err)
|
|
|
|
return err;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
sbi->s_buddy_cache = new_inode(sb);
|
|
|
|
if (sbi->s_buddy_cache == NULL) {
|
2011-08-01 21:41:35 +00:00
|
|
|
ext4_msg(sb, KERN_ERR, "can't get new inode");
|
2008-01-29 05:19:52 +00:00
|
|
|
goto err_freesgi;
|
|
|
|
}
|
2011-08-01 21:41:39 +00:00
|
|
|
/* To avoid potentially colliding with an valid on-disk inode number,
|
|
|
|
* use EXT4_BAD_INO for the buddy cache inode number. This inode is
|
|
|
|
* not in the inode hash, so it should never be found by iget(), but
|
|
|
|
* this will avoid confusion if it ever shows up during debugging. */
|
|
|
|
sbi->s_buddy_cache->i_ino = EXT4_BAD_INO;
|
2008-01-29 05:19:52 +00:00
|
|
|
EXT4_I(sbi->s_buddy_cache)->i_disksize = 0;
|
2009-05-01 12:50:38 +00:00
|
|
|
for (i = 0; i < ngroups; i++) {
|
2019-04-25 16:58:01 +00:00
|
|
|
cond_resched();
|
2008-01-29 05:19:52 +00:00
|
|
|
desc = ext4_get_group_desc(sb, i, NULL);
|
|
|
|
if (desc == NULL) {
|
2011-08-01 21:41:35 +00:00
|
|
|
ext4_msg(sb, KERN_ERR, "can't read descriptor %u", i);
|
2008-01-29 05:19:52 +00:00
|
|
|
goto err_freebuddy;
|
|
|
|
}
|
2008-07-11 23:27:31 +00:00
|
|
|
if (ext4_mb_add_groupinfo(sb, i, desc) != 0)
|
|
|
|
goto err_freebuddy;
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
2020-04-21 07:54:07 +00:00
|
|
|
if (ext4_has_feature_flex_bg(sb)) {
|
2021-02-24 09:58:00 +00:00
|
|
|
/* a single flex group is supposed to be read by a single IO.
|
|
|
|
* 2 ^ s_log_groups_per_flex != UINT_MAX as s_mb_prefetch is
|
|
|
|
* unsigned integer, so the maximum shift is 32.
|
|
|
|
*/
|
|
|
|
if (sbi->s_es->s_log_groups_per_flex >= 32) {
|
|
|
|
ext4_msg(sb, KERN_ERR, "too many log groups per flexible block group");
|
2021-04-12 07:38:37 +00:00
|
|
|
goto err_freebuddy;
|
2021-02-24 09:58:00 +00:00
|
|
|
}
|
|
|
|
sbi->s_mb_prefetch = min_t(uint, 1 << sbi->s_es->s_log_groups_per_flex,
|
ext4: avoid s_mb_prefetch to be zero in individual scenarios
Commit cfd732377221 ("ext4: add prefetching for block allocation
bitmaps") introduced block bitmap prefetch, and expects to read block
bitmaps of flex_bg through an IO. However, it seems to ignore the
value range of s_log_groups_per_flex. In the scenario where the value
of s_log_groups_per_flex is greater than 27, s_mb_prefetch or
s_mb_prefetch_limit will overflow, cause a divide zero exception.
In addition, the logic of calculating nr is also flawed, because the
size of flexbg is fixed during a single mount, but s_mb_prefetch can
be modified, which causes nr to fail to meet the value condition of
[1, flexbg_size].
To solve this problem, we need to set the upper limit of
s_mb_prefetch. Since we expect to load block bitmaps of a flex_bg
through an IO, we can consider determining a reasonable upper limit
among the IO limit parameters. After consideration, we chose
BLK_MAX_SEGMENT_SIZE. This is a good choice to solve divide zero
problem and avoiding performance degradation.
[ Some minor code simplifications to make the changes easy to follow -- TYT ]
Reported-by: Tosk Robot <tencent_os_robot@tencent.com>
Signed-off-by: Chunguang Xu <brookxu@tencent.com>
Reviewed-by: Samuel Liao <samuelliao@tencent.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/1607051143-24508-1-git-send-email-brookxu@tencent.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2020-12-04 03:05:43 +00:00
|
|
|
BLK_MAX_SEGMENT_SIZE >> (sb->s_blocksize_bits - 9));
|
2020-04-21 07:54:07 +00:00
|
|
|
sbi->s_mb_prefetch *= 8; /* 8 prefetch IOs in flight at most */
|
|
|
|
} else {
|
|
|
|
sbi->s_mb_prefetch = 32;
|
|
|
|
}
|
|
|
|
if (sbi->s_mb_prefetch > ext4_get_groups_count(sb))
|
|
|
|
sbi->s_mb_prefetch = ext4_get_groups_count(sb);
|
2024-04-24 06:19:03 +00:00
|
|
|
/*
|
|
|
|
* now many real IOs to prefetch within a single allocation at
|
|
|
|
* CR_POWER2_ALIGNED. Given CR_POWER2_ALIGNED is an CPU-related
|
|
|
|
* optimization we shouldn't try to load too many groups, at some point
|
|
|
|
* we should start to use what we've got in memory.
|
2020-04-21 07:54:07 +00:00
|
|
|
* with an average random access time 5ms, it'd take a second to get
|
|
|
|
* 200 groups (* N with flex_bg), so let's make this limit 4
|
|
|
|
*/
|
|
|
|
sbi->s_mb_prefetch_limit = sbi->s_mb_prefetch * 4;
|
|
|
|
if (sbi->s_mb_prefetch_limit > ext4_get_groups_count(sb))
|
|
|
|
sbi->s_mb_prefetch_limit = ext4_get_groups_count(sb);
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_freebuddy:
|
2010-10-28 01:29:12 +00:00
|
|
|
cachep = get_groupinfo_cache(sb->s_blocksize_bits);
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
while (i-- > 0) {
|
|
|
|
struct ext4_group_info *grp = ext4_get_group_info(sb, i);
|
|
|
|
|
|
|
|
if (grp)
|
|
|
|
kmem_cache_free(cachep, grp);
|
|
|
|
}
|
2012-09-05 05:31:50 +00:00
|
|
|
i = sbi->s_group_info_size;
|
2020-02-19 03:08:50 +00:00
|
|
|
rcu_read_lock();
|
|
|
|
group_info = rcu_dereference(sbi->s_group_info);
|
2008-04-30 02:01:15 +00:00
|
|
|
while (i-- > 0)
|
2020-02-19 03:08:50 +00:00
|
|
|
kfree(group_info[i]);
|
|
|
|
rcu_read_unlock();
|
2008-01-29 05:19:52 +00:00
|
|
|
iput(sbi->s_buddy_cache);
|
|
|
|
err_freesgi:
|
2020-02-19 03:08:50 +00:00
|
|
|
rcu_read_lock();
|
|
|
|
kvfree(rcu_dereference(sbi->s_group_info));
|
|
|
|
rcu_read_unlock();
|
2008-01-29 05:19:52 +00:00
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
2011-02-12 13:12:18 +00:00
|
|
|
static void ext4_groupinfo_destroy_slabs(void)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < NR_GRPINFO_CACHES; i++) {
|
2018-05-21 02:44:13 +00:00
|
|
|
kmem_cache_destroy(ext4_groupinfo_caches[i]);
|
2011-02-12 13:12:18 +00:00
|
|
|
ext4_groupinfo_caches[i] = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int ext4_groupinfo_create_slab(size_t size)
|
|
|
|
{
|
|
|
|
static DEFINE_MUTEX(ext4_grpinfo_slab_create_mutex);
|
|
|
|
int slab_size;
|
|
|
|
int blocksize_bits = order_base_2(size);
|
|
|
|
int cache_index = blocksize_bits - EXT4_MIN_BLOCK_LOG_SIZE;
|
|
|
|
struct kmem_cache *cachep;
|
|
|
|
|
|
|
|
if (cache_index >= NR_GRPINFO_CACHES)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (unlikely(cache_index < 0))
|
|
|
|
cache_index = 0;
|
|
|
|
|
|
|
|
mutex_lock(&ext4_grpinfo_slab_create_mutex);
|
|
|
|
if (ext4_groupinfo_caches[cache_index]) {
|
|
|
|
mutex_unlock(&ext4_grpinfo_slab_create_mutex);
|
|
|
|
return 0; /* Already created */
|
|
|
|
}
|
|
|
|
|
|
|
|
slab_size = offsetof(struct ext4_group_info,
|
|
|
|
bb_counters[blocksize_bits + 2]);
|
|
|
|
|
|
|
|
cachep = kmem_cache_create(ext4_groupinfo_slab_names[cache_index],
|
|
|
|
slab_size, 0, SLAB_RECLAIM_ACCOUNT,
|
|
|
|
NULL);
|
|
|
|
|
2011-07-11 22:26:01 +00:00
|
|
|
ext4_groupinfo_caches[cache_index] = cachep;
|
|
|
|
|
2011-02-12 13:12:18 +00:00
|
|
|
mutex_unlock(&ext4_grpinfo_slab_create_mutex);
|
|
|
|
if (!cachep) {
|
2011-08-01 21:41:35 +00:00
|
|
|
printk(KERN_EMERG
|
|
|
|
"EXT4-fs: no memory for groupinfo slab cache\n");
|
2011-02-12 13:12:18 +00:00
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-07-24 07:41:23 +00:00
|
|
|
static void ext4_discard_work(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct ext4_sb_info *sbi = container_of(work,
|
|
|
|
struct ext4_sb_info, s_discard_work);
|
|
|
|
struct super_block *sb = sbi->s_sb;
|
|
|
|
struct ext4_free_data *fd, *nfd;
|
|
|
|
struct ext4_buddy e4b;
|
2023-08-12 07:18:39 +00:00
|
|
|
LIST_HEAD(discard_list);
|
2021-07-24 07:41:23 +00:00
|
|
|
ext4_group_t grp, load_grp;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
spin_lock(&sbi->s_md_lock);
|
|
|
|
list_splice_init(&sbi->s_discard_list, &discard_list);
|
|
|
|
spin_unlock(&sbi->s_md_lock);
|
|
|
|
|
|
|
|
load_grp = UINT_MAX;
|
|
|
|
list_for_each_entry_safe(fd, nfd, &discard_list, efd_list) {
|
|
|
|
/*
|
2021-08-30 07:52:46 +00:00
|
|
|
* If filesystem is umounting or no memory or suffering
|
|
|
|
* from no space, give up the discard
|
2021-07-24 07:41:23 +00:00
|
|
|
*/
|
2021-08-30 07:52:46 +00:00
|
|
|
if ((sb->s_flags & SB_ACTIVE) && !err &&
|
|
|
|
!atomic_read(&sbi->s_retry_alloc_pending)) {
|
2021-07-24 07:41:23 +00:00
|
|
|
grp = fd->efd_group;
|
|
|
|
if (grp != load_grp) {
|
|
|
|
if (load_grp != UINT_MAX)
|
|
|
|
ext4_mb_unload_buddy(&e4b);
|
|
|
|
|
|
|
|
err = ext4_mb_load_buddy(sb, grp, &e4b);
|
|
|
|
if (err) {
|
|
|
|
kmem_cache_free(ext4_free_data_cachep, fd);
|
|
|
|
load_grp = UINT_MAX;
|
|
|
|
continue;
|
|
|
|
} else {
|
|
|
|
load_grp = grp;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
ext4_lock_group(sb, grp);
|
|
|
|
ext4_try_to_trim_range(sb, &e4b, fd->efd_start_cluster,
|
|
|
|
fd->efd_start_cluster + fd->efd_count - 1, 1);
|
|
|
|
ext4_unlock_group(sb, grp);
|
|
|
|
}
|
|
|
|
kmem_cache_free(ext4_free_data_cachep, fd);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (load_grp != UINT_MAX)
|
|
|
|
ext4_mb_unload_buddy(&e4b);
|
|
|
|
}
|
|
|
|
|
2012-05-28 18:19:25 +00:00
|
|
|
int ext4_mb_init(struct super_block *sb)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
2008-07-23 18:14:05 +00:00
|
|
|
unsigned i, j;
|
ext4: silence UBSAN in ext4_mb_init()
Currently, in ext4_mb_init(), there's a loop like the following:
do {
...
offset += 1 << (sb->s_blocksize_bits - i);
i++;
} while (i <= sb->s_blocksize_bits + 1);
Note that the updated offset is used in the loop's next iteration only.
However, at the last iteration, that is at i == sb->s_blocksize_bits + 1,
the shift count becomes equal to (unsigned)-1 > 31 (c.f. C99 6.5.7(3))
and UBSAN reports
UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2621:15
shift exponent 4294967295 is too large for 32-bit type 'int'
[...]
Call Trace:
[<ffffffff818c4d25>] dump_stack+0xbc/0x117
[<ffffffff818c4c69>] ? _atomic_dec_and_lock+0x169/0x169
[<ffffffff819411ab>] ubsan_epilogue+0xd/0x4e
[<ffffffff81941cac>] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
[<ffffffff81941ab1>] ? __ubsan_handle_load_invalid_value+0x158/0x158
[<ffffffff814b6dc1>] ? kmem_cache_alloc+0x101/0x390
[<ffffffff816fc13b>] ? ext4_mb_init+0x13b/0xfd0
[<ffffffff814293c7>] ? create_cache+0x57/0x1f0
[<ffffffff8142948a>] ? create_cache+0x11a/0x1f0
[<ffffffff821c2168>] ? mutex_lock+0x38/0x60
[<ffffffff821c23ab>] ? mutex_unlock+0x1b/0x50
[<ffffffff814c26ab>] ? put_online_mems+0x5b/0xc0
[<ffffffff81429677>] ? kmem_cache_create+0x117/0x2c0
[<ffffffff816fcc49>] ext4_mb_init+0xc49/0xfd0
[...]
Observe that the mentioned shift exponent, 4294967295, equals (unsigned)-1.
Unless compilers start to do some fancy transformations (which at least
GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the
such calculated value of offset is never used again.
Silence UBSAN by introducing another variable, offset_incr, holding the
next increment to apply to offset and adjust that one by right shifting it
by one position per loop iteration.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161
Cc: stable@vger.kernel.org
Signed-off-by: Nicolai Stange <nicstange@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2016-05-05 23:46:19 +00:00
|
|
|
unsigned offset, offset_incr;
|
2008-01-29 05:19:52 +00:00
|
|
|
unsigned max;
|
2008-07-11 23:27:31 +00:00
|
|
|
int ret;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2021-04-01 17:21:26 +00:00
|
|
|
i = MB_NUM_ORDERS(sb) * sizeof(*sbi->s_mb_offsets);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
sbi->s_mb_offsets = kmalloc(i, GFP_KERNEL);
|
|
|
|
if (sbi->s_mb_offsets == NULL) {
|
2010-10-28 01:29:12 +00:00
|
|
|
ret = -ENOMEM;
|
|
|
|
goto out;
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2008-12-17 05:48:39 +00:00
|
|
|
|
2021-04-01 17:21:26 +00:00
|
|
|
i = MB_NUM_ORDERS(sb) * sizeof(*sbi->s_mb_maxs);
|
2008-01-29 05:19:52 +00:00
|
|
|
sbi->s_mb_maxs = kmalloc(i, GFP_KERNEL);
|
|
|
|
if (sbi->s_mb_maxs == NULL) {
|
2010-10-28 01:29:12 +00:00
|
|
|
ret = -ENOMEM;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2011-02-12 13:12:18 +00:00
|
|
|
ret = ext4_groupinfo_create_slab(sb->s_blocksize);
|
|
|
|
if (ret < 0)
|
|
|
|
goto out;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
/* order 0 is regular bitmap */
|
|
|
|
sbi->s_mb_maxs[0] = sb->s_blocksize << 3;
|
|
|
|
sbi->s_mb_offsets[0] = 0;
|
|
|
|
|
|
|
|
i = 1;
|
|
|
|
offset = 0;
|
ext4: silence UBSAN in ext4_mb_init()
Currently, in ext4_mb_init(), there's a loop like the following:
do {
...
offset += 1 << (sb->s_blocksize_bits - i);
i++;
} while (i <= sb->s_blocksize_bits + 1);
Note that the updated offset is used in the loop's next iteration only.
However, at the last iteration, that is at i == sb->s_blocksize_bits + 1,
the shift count becomes equal to (unsigned)-1 > 31 (c.f. C99 6.5.7(3))
and UBSAN reports
UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2621:15
shift exponent 4294967295 is too large for 32-bit type 'int'
[...]
Call Trace:
[<ffffffff818c4d25>] dump_stack+0xbc/0x117
[<ffffffff818c4c69>] ? _atomic_dec_and_lock+0x169/0x169
[<ffffffff819411ab>] ubsan_epilogue+0xd/0x4e
[<ffffffff81941cac>] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
[<ffffffff81941ab1>] ? __ubsan_handle_load_invalid_value+0x158/0x158
[<ffffffff814b6dc1>] ? kmem_cache_alloc+0x101/0x390
[<ffffffff816fc13b>] ? ext4_mb_init+0x13b/0xfd0
[<ffffffff814293c7>] ? create_cache+0x57/0x1f0
[<ffffffff8142948a>] ? create_cache+0x11a/0x1f0
[<ffffffff821c2168>] ? mutex_lock+0x38/0x60
[<ffffffff821c23ab>] ? mutex_unlock+0x1b/0x50
[<ffffffff814c26ab>] ? put_online_mems+0x5b/0xc0
[<ffffffff81429677>] ? kmem_cache_create+0x117/0x2c0
[<ffffffff816fcc49>] ext4_mb_init+0xc49/0xfd0
[...]
Observe that the mentioned shift exponent, 4294967295, equals (unsigned)-1.
Unless compilers start to do some fancy transformations (which at least
GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the
such calculated value of offset is never used again.
Silence UBSAN by introducing another variable, offset_incr, holding the
next increment to apply to offset and adjust that one by right shifting it
by one position per loop iteration.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161
Cc: stable@vger.kernel.org
Signed-off-by: Nicolai Stange <nicstange@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2016-05-05 23:46:19 +00:00
|
|
|
offset_incr = 1 << (sb->s_blocksize_bits - 1);
|
2008-01-29 05:19:52 +00:00
|
|
|
max = sb->s_blocksize << 2;
|
|
|
|
do {
|
|
|
|
sbi->s_mb_offsets[i] = offset;
|
|
|
|
sbi->s_mb_maxs[i] = max;
|
ext4: silence UBSAN in ext4_mb_init()
Currently, in ext4_mb_init(), there's a loop like the following:
do {
...
offset += 1 << (sb->s_blocksize_bits - i);
i++;
} while (i <= sb->s_blocksize_bits + 1);
Note that the updated offset is used in the loop's next iteration only.
However, at the last iteration, that is at i == sb->s_blocksize_bits + 1,
the shift count becomes equal to (unsigned)-1 > 31 (c.f. C99 6.5.7(3))
and UBSAN reports
UBSAN: Undefined behaviour in fs/ext4/mballoc.c:2621:15
shift exponent 4294967295 is too large for 32-bit type 'int'
[...]
Call Trace:
[<ffffffff818c4d25>] dump_stack+0xbc/0x117
[<ffffffff818c4c69>] ? _atomic_dec_and_lock+0x169/0x169
[<ffffffff819411ab>] ubsan_epilogue+0xd/0x4e
[<ffffffff81941cac>] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
[<ffffffff81941ab1>] ? __ubsan_handle_load_invalid_value+0x158/0x158
[<ffffffff814b6dc1>] ? kmem_cache_alloc+0x101/0x390
[<ffffffff816fc13b>] ? ext4_mb_init+0x13b/0xfd0
[<ffffffff814293c7>] ? create_cache+0x57/0x1f0
[<ffffffff8142948a>] ? create_cache+0x11a/0x1f0
[<ffffffff821c2168>] ? mutex_lock+0x38/0x60
[<ffffffff821c23ab>] ? mutex_unlock+0x1b/0x50
[<ffffffff814c26ab>] ? put_online_mems+0x5b/0xc0
[<ffffffff81429677>] ? kmem_cache_create+0x117/0x2c0
[<ffffffff816fcc49>] ext4_mb_init+0xc49/0xfd0
[...]
Observe that the mentioned shift exponent, 4294967295, equals (unsigned)-1.
Unless compilers start to do some fancy transformations (which at least
GCC 6.0.0 doesn't currently do), the issue is of cosmetic nature only: the
such calculated value of offset is never used again.
Silence UBSAN by introducing another variable, offset_incr, holding the
next increment to apply to offset and adjust that one by right shifting it
by one position per loop iteration.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=114701
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=112161
Cc: stable@vger.kernel.org
Signed-off-by: Nicolai Stange <nicstange@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2016-05-05 23:46:19 +00:00
|
|
|
offset += offset_incr;
|
|
|
|
offset_incr = offset_incr >> 1;
|
2008-01-29 05:19:52 +00:00
|
|
|
max = max >> 1;
|
|
|
|
i++;
|
2021-04-01 17:21:26 +00:00
|
|
|
} while (i < MB_NUM_ORDERS(sb));
|
|
|
|
|
2022-09-08 09:21:28 +00:00
|
|
|
sbi->s_mb_avg_fragment_size =
|
|
|
|
kmalloc_array(MB_NUM_ORDERS(sb), sizeof(struct list_head),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!sbi->s_mb_avg_fragment_size) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
sbi->s_mb_avg_fragment_size_locks =
|
|
|
|
kmalloc_array(MB_NUM_ORDERS(sb), sizeof(rwlock_t),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!sbi->s_mb_avg_fragment_size_locks) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
for (i = 0; i < MB_NUM_ORDERS(sb); i++) {
|
|
|
|
INIT_LIST_HEAD(&sbi->s_mb_avg_fragment_size[i]);
|
|
|
|
rwlock_init(&sbi->s_mb_avg_fragment_size_locks[i]);
|
|
|
|
}
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
sbi->s_mb_largest_free_orders =
|
|
|
|
kmalloc_array(MB_NUM_ORDERS(sb), sizeof(struct list_head),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!sbi->s_mb_largest_free_orders) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
sbi->s_mb_largest_free_orders_locks =
|
|
|
|
kmalloc_array(MB_NUM_ORDERS(sb), sizeof(rwlock_t),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!sbi->s_mb_largest_free_orders_locks) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
for (i = 0; i < MB_NUM_ORDERS(sb); i++) {
|
|
|
|
INIT_LIST_HEAD(&sbi->s_mb_largest_free_orders[i]);
|
|
|
|
rwlock_init(&sbi->s_mb_largest_free_orders_locks[i]);
|
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
spin_lock_init(&sbi->s_md_lock);
|
2016-06-26 22:24:01 +00:00
|
|
|
sbi->s_mb_free_pending = 0;
|
2023-06-12 12:40:17 +00:00
|
|
|
INIT_LIST_HEAD(&sbi->s_freed_data_list[0]);
|
|
|
|
INIT_LIST_HEAD(&sbi->s_freed_data_list[1]);
|
2021-07-24 07:41:23 +00:00
|
|
|
INIT_LIST_HEAD(&sbi->s_discard_list);
|
|
|
|
INIT_WORK(&sbi->s_discard_work, ext4_discard_work);
|
2021-08-30 07:52:46 +00:00
|
|
|
atomic_set(&sbi->s_retry_alloc_pending, 0);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
sbi->s_mb_max_to_scan = MB_DEFAULT_MAX_TO_SCAN;
|
|
|
|
sbi->s_mb_min_to_scan = MB_DEFAULT_MIN_TO_SCAN;
|
|
|
|
sbi->s_mb_stats = MB_DEFAULT_STATS;
|
|
|
|
sbi->s_mb_stream_request = MB_DEFAULT_STREAM_THRESHOLD;
|
|
|
|
sbi->s_mb_order2_reqs = MB_DEFAULT_ORDER2_REQS;
|
2023-05-30 12:33:50 +00:00
|
|
|
sbi->s_mb_best_avail_max_trim_order = MB_DEFAULT_BEST_AVAIL_TRIM_ORDER;
|
2023-05-30 12:33:49 +00:00
|
|
|
|
2011-09-09 23:02:51 +00:00
|
|
|
/*
|
|
|
|
* The default group preallocation is 512, which for 4k block
|
|
|
|
* sizes translates to 2 megabytes. However for bigalloc file
|
|
|
|
* systems, this is probably too big (i.e, if the cluster size
|
|
|
|
* is 1 megabyte, then group preallocation size becomes half a
|
|
|
|
* gigabyte!). As a default, we will keep a two megabyte
|
|
|
|
* group pralloc size for cluster sizes up to 64k, and after
|
|
|
|
* that, we will force a minimum group preallocation size of
|
|
|
|
* 32 clusters. This translates to 8 megs when the cluster
|
|
|
|
* size is 256k, and 32 megs when the cluster size is 1 meg,
|
|
|
|
* which seems reasonable as a default.
|
|
|
|
*/
|
|
|
|
sbi->s_mb_group_prealloc = max(MB_DEFAULT_GROUP_PREALLOC >>
|
|
|
|
sbi->s_cluster_bits, 32);
|
2011-07-18 01:11:30 +00:00
|
|
|
/*
|
|
|
|
* If there is a s_stripe > 1, then we set the s_mb_group_prealloc
|
|
|
|
* to the lowest multiple of s_stripe which is bigger than
|
|
|
|
* the s_mb_group_prealloc as determined above. We want
|
|
|
|
* the preallocation size to be an exact multiple of the
|
|
|
|
* RAID stripe size so that preallocations don't fragment
|
|
|
|
* the stripes.
|
|
|
|
*/
|
|
|
|
if (sbi->s_stripe > 1) {
|
|
|
|
sbi->s_mb_group_prealloc = roundup(
|
2024-08-30 07:20:58 +00:00
|
|
|
sbi->s_mb_group_prealloc, EXT4_NUM_B2C(sbi, sbi->s_stripe));
|
2011-07-18 01:11:30 +00:00
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2008-09-13 19:23:29 +00:00
|
|
|
sbi->s_locality_groups = alloc_percpu(struct ext4_locality_group);
|
2008-01-29 05:19:52 +00:00
|
|
|
if (sbi->s_locality_groups == NULL) {
|
2010-10-28 01:29:12 +00:00
|
|
|
ret = -ENOMEM;
|
2014-05-12 16:34:21 +00:00
|
|
|
goto out;
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2008-09-13 19:23:29 +00:00
|
|
|
for_each_possible_cpu(i) {
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_locality_group *lg;
|
2008-09-13 19:23:29 +00:00
|
|
|
lg = per_cpu_ptr(sbi->s_locality_groups, i);
|
2008-01-29 05:19:52 +00:00
|
|
|
mutex_init(&lg->lg_mutex);
|
2008-07-23 18:14:05 +00:00
|
|
|
for (j = 0; j < PREALLOC_TB_SIZE; j++)
|
|
|
|
INIT_LIST_HEAD(&lg->lg_prealloc_list[j]);
|
2008-01-29 05:19:52 +00:00
|
|
|
spin_lock_init(&lg->lg_prealloc_lock);
|
|
|
|
}
|
|
|
|
|
2022-04-15 04:52:42 +00:00
|
|
|
if (bdev_nonrot(sb->s_bdev))
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
sbi->s_mb_max_linear_groups = 0;
|
|
|
|
else
|
|
|
|
sbi->s_mb_max_linear_groups = MB_DEFAULT_LINEAR_LIMIT;
|
2011-08-01 21:41:46 +00:00
|
|
|
/* init file for buddy data */
|
|
|
|
ret = ext4_mb_init_backend(sb);
|
2011-10-06 14:22:28 +00:00
|
|
|
if (ret != 0)
|
|
|
|
goto out_free_locality_groups;
|
2011-08-01 21:41:46 +00:00
|
|
|
|
2011-10-06 14:22:28 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
out_free_locality_groups:
|
|
|
|
free_percpu(sbi->s_locality_groups);
|
|
|
|
sbi->s_locality_groups = NULL;
|
2010-10-28 01:29:12 +00:00
|
|
|
out:
|
2022-09-08 09:21:28 +00:00
|
|
|
kfree(sbi->s_mb_avg_fragment_size);
|
|
|
|
kfree(sbi->s_mb_avg_fragment_size_locks);
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
kfree(sbi->s_mb_largest_free_orders);
|
|
|
|
kfree(sbi->s_mb_largest_free_orders_locks);
|
2011-10-06 14:22:28 +00:00
|
|
|
kfree(sbi->s_mb_offsets);
|
|
|
|
sbi->s_mb_offsets = NULL;
|
|
|
|
kfree(sbi->s_mb_maxs);
|
|
|
|
sbi->s_mb_maxs = NULL;
|
2010-10-28 01:29:12 +00:00
|
|
|
return ret;
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
2009-05-03 00:35:09 +00:00
|
|
|
/* need to called with the ext4 group lock held */
|
2020-05-10 06:24:54 +00:00
|
|
|
static int ext4_mb_cleanup_pa(struct ext4_group_info *grp)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
|
|
|
struct ext4_prealloc_space *pa;
|
|
|
|
struct list_head *cur, *tmp;
|
|
|
|
int count = 0;
|
|
|
|
|
|
|
|
list_for_each_safe(cur, tmp, &grp->bb_prealloc_list) {
|
|
|
|
pa = list_entry(cur, struct ext4_prealloc_space, pa_group_list);
|
|
|
|
list_del(&pa->pa_group_list);
|
|
|
|
count++;
|
2008-10-13 16:14:14 +00:00
|
|
|
kmem_cache_free(ext4_pspace_cachep, pa);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2020-05-10 06:24:54 +00:00
|
|
|
return count;
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
2024-01-05 09:20:58 +00:00
|
|
|
void ext4_mb_release(struct super_block *sb)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
2009-05-01 12:50:38 +00:00
|
|
|
ext4_group_t ngroups = ext4_get_groups_count(sb);
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_group_t i;
|
|
|
|
int num_meta_group_infos;
|
2020-02-19 03:08:50 +00:00
|
|
|
struct ext4_group_info *grinfo, ***group_info;
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
2010-10-28 01:29:12 +00:00
|
|
|
struct kmem_cache *cachep = get_groupinfo_cache(sb->s_blocksize_bits);
|
2020-05-10 06:24:54 +00:00
|
|
|
int count;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2021-07-24 07:41:23 +00:00
|
|
|
if (test_opt(sb, DISCARD)) {
|
|
|
|
/*
|
|
|
|
* wait the discard work to drain all of ext4_free_data
|
|
|
|
*/
|
|
|
|
flush_work(&sbi->s_discard_work);
|
|
|
|
WARN_ON_ONCE(!list_empty(&sbi->s_discard_list));
|
|
|
|
}
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
if (sbi->s_group_info) {
|
2009-05-01 12:50:38 +00:00
|
|
|
for (i = 0; i < ngroups; i++) {
|
2019-04-25 16:58:01 +00:00
|
|
|
cond_resched();
|
2008-01-29 05:19:52 +00:00
|
|
|
grinfo = ext4_get_group_info(sb, i);
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
if (!grinfo)
|
|
|
|
continue;
|
2020-05-10 06:24:48 +00:00
|
|
|
mb_group_bb_bitmap_free(grinfo);
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_lock_group(sb, i);
|
2020-05-10 06:24:54 +00:00
|
|
|
count = ext4_mb_cleanup_pa(grinfo);
|
|
|
|
if (count)
|
|
|
|
mb_debug(sb, "mballoc: %d PAs left\n",
|
|
|
|
count);
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_unlock_group(sb, i);
|
2010-10-28 01:29:12 +00:00
|
|
|
kmem_cache_free(cachep, grinfo);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2009-05-01 12:50:38 +00:00
|
|
|
num_meta_group_infos = (ngroups +
|
2008-01-29 05:19:52 +00:00
|
|
|
EXT4_DESC_PER_BLOCK(sb) - 1) >>
|
|
|
|
EXT4_DESC_PER_BLOCK_BITS(sb);
|
2020-02-19 03:08:50 +00:00
|
|
|
rcu_read_lock();
|
|
|
|
group_info = rcu_dereference(sbi->s_group_info);
|
2008-01-29 05:19:52 +00:00
|
|
|
for (i = 0; i < num_meta_group_infos; i++)
|
2020-02-19 03:08:50 +00:00
|
|
|
kfree(group_info[i]);
|
|
|
|
kvfree(group_info);
|
|
|
|
rcu_read_unlock();
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2022-09-08 09:21:28 +00:00
|
|
|
kfree(sbi->s_mb_avg_fragment_size);
|
|
|
|
kfree(sbi->s_mb_avg_fragment_size_locks);
|
ext4: improve cr 0 / cr 1 group scanning
Instead of traversing through groups linearly, scan groups in specific
orders at cr 0 and cr 1. At cr 0, we want to find groups that have the
largest free order >= the order of the request. So, with this patch,
we maintain lists for each possible order and insert each group into a
list based on the largest free order in its buddy bitmap. During cr 0
allocation, we traverse these lists in the increasing order of largest
free orders. This allows us to find a group with the best available cr
0 match in constant time. If nothing can be found, we fallback to cr 1
immediately.
At CR1, the story is slightly different. We want to traverse in the
order of increasing average fragment size. For CR1, we maintain a rb
tree of groupinfos which is sorted by average fragment size. Instead
of traversing linearly, at CR1, we traverse in the order of increasing
average fragment size, starting at the most optimal group. This brings
down cr 1 search complexity to log(num groups).
For cr >= 2, we just perform the linear search as before. Also, in
case of lock contention, we intermittently fallback to linear search
even in CR 0 and CR 1 cases. This allows us to proceed during the
allocation path even in case of high contention.
There is an opportunity to do optimization at CR2 too. That's because
at CR2 we only consider groups where bb_free counter (number of free
blocks) is greater than the request extent size. That's left as future
work.
All the changes introduced in this patch are protected under a new
mount option "mb_optimize_scan".
With this patchset, following experiment was performed:
Created a highly fragmented disk of size 65TB. The disk had no
contiguous 2M regions. Following command was run consecutively for 3
times:
time dd if=/dev/urandom of=file bs=2M count=10
Here are the results with and without cr 0/1 optimizations introduced
in this patch:
|---------+------------------------------+---------------------------|
| | Without CR 0/1 Optimizations | With CR 0/1 Optimizations |
|---------+------------------------------+---------------------------|
| 1st run | 5m1.871s | 2m47.642s |
| 2nd run | 2m28.390s | 0m0.611s |
| 3rd run | 2m26.530s | 0m1.255s |
|---------+------------------------------+---------------------------|
Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20210401172129.189766-6-harshadshirwadkar@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-04-01 17:21:27 +00:00
|
|
|
kfree(sbi->s_mb_largest_free_orders);
|
|
|
|
kfree(sbi->s_mb_largest_free_orders_locks);
|
2008-01-29 05:19:52 +00:00
|
|
|
kfree(sbi->s_mb_offsets);
|
|
|
|
kfree(sbi->s_mb_maxs);
|
2014-11-26 01:01:37 +00:00
|
|
|
iput(sbi->s_buddy_cache);
|
2008-01-29 05:19:52 +00:00
|
|
|
if (sbi->s_mb_stats) {
|
2011-08-01 21:41:35 +00:00
|
|
|
ext4_msg(sb, KERN_INFO,
|
|
|
|
"mballoc: %u blocks %u reqs (%u success)",
|
2008-01-29 05:19:52 +00:00
|
|
|
atomic_read(&sbi->s_bal_allocated),
|
|
|
|
atomic_read(&sbi->s_bal_reqs),
|
|
|
|
atomic_read(&sbi->s_bal_success));
|
2011-08-01 21:41:35 +00:00
|
|
|
ext4_msg(sb, KERN_INFO,
|
2021-04-01 17:21:25 +00:00
|
|
|
"mballoc: %u extents scanned, %u groups scanned, %u goal hits, "
|
2011-08-01 21:41:35 +00:00
|
|
|
"%u 2^N hits, %u breaks, %u lost",
|
2008-01-29 05:19:52 +00:00
|
|
|
atomic_read(&sbi->s_bal_ex_scanned),
|
2021-04-01 17:21:25 +00:00
|
|
|
atomic_read(&sbi->s_bal_groups_scanned),
|
2008-01-29 05:19:52 +00:00
|
|
|
atomic_read(&sbi->s_bal_goals),
|
|
|
|
atomic_read(&sbi->s_bal_2orders),
|
|
|
|
atomic_read(&sbi->s_bal_breaks),
|
|
|
|
atomic_read(&sbi->s_mb_lost_chunks));
|
2011-08-01 21:41:35 +00:00
|
|
|
ext4_msg(sb, KERN_INFO,
|
2021-04-01 17:21:23 +00:00
|
|
|
"mballoc: %u generated and it took %llu",
|
|
|
|
atomic_read(&sbi->s_mb_buddies_generated),
|
|
|
|
atomic64_read(&sbi->s_mb_generation_time));
|
2011-08-01 21:41:35 +00:00
|
|
|
ext4_msg(sb, KERN_INFO,
|
|
|
|
"mballoc: %u preallocated, %u discarded",
|
2008-01-29 05:19:52 +00:00
|
|
|
atomic_read(&sbi->s_mb_preallocated),
|
|
|
|
atomic_read(&sbi->s_mb_discarded));
|
|
|
|
}
|
|
|
|
|
2008-09-13 19:23:29 +00:00
|
|
|
free_percpu(sbi->s_locality_groups);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
2010-10-28 01:30:11 +00:00
|
|
|
static inline int ext4_issue_discard(struct super_block *sb,
|
2024-02-26 08:17:31 +00:00
|
|
|
ext4_group_t block_group, ext4_grpblk_t cluster, int count)
|
2010-07-27 15:56:05 +00:00
|
|
|
{
|
|
|
|
ext4_fsblk_t discard_block;
|
|
|
|
|
2011-09-09 22:50:51 +00:00
|
|
|
discard_block = (EXT4_C2B(EXT4_SB(sb), cluster) +
|
|
|
|
ext4_group_first_block_no(sb, block_group));
|
|
|
|
count = EXT4_C2B(EXT4_SB(sb), count);
|
2010-07-27 15:56:05 +00:00
|
|
|
trace_ext4_discard_blocks(sb,
|
|
|
|
(unsigned long long) discard_block, count);
|
2024-02-26 08:17:31 +00:00
|
|
|
|
|
|
|
return sb_issue_discard(sb, discard_block, count, GFP_NOFS, 0);
|
2010-07-27 15:56:05 +00:00
|
|
|
}
|
|
|
|
|
2017-06-23 03:54:33 +00:00
|
|
|
static void ext4_free_data_in_buddy(struct super_block *sb,
|
|
|
|
struct ext4_free_data *entry)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
|
|
|
struct ext4_buddy e4b;
|
2008-10-16 14:14:27 +00:00
|
|
|
struct ext4_group_info *db;
|
2023-03-03 17:21:16 +00:00
|
|
|
int err, count = 0;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "gonna free %u blocks in group %u (0x%p):",
|
2012-02-20 22:53:02 +00:00
|
|
|
entry->efd_count, entry->efd_group, entry);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2012-02-20 22:53:02 +00:00
|
|
|
err = ext4_mb_load_buddy(sb, entry->efd_group, &e4b);
|
|
|
|
/* we expect to find existing buddy because it's pinned */
|
|
|
|
BUG_ON(err != 0);
|
2010-04-20 20:51:59 +00:00
|
|
|
|
2016-06-26 22:24:01 +00:00
|
|
|
spin_lock(&EXT4_SB(sb)->s_md_lock);
|
|
|
|
EXT4_SB(sb)->s_mb_free_pending -= entry->efd_count;
|
|
|
|
spin_unlock(&EXT4_SB(sb)->s_md_lock);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2012-02-20 22:53:02 +00:00
|
|
|
db = e4b.bd_info;
|
|
|
|
/* there are blocks to put in buddy to make them really free */
|
|
|
|
count += entry->efd_count;
|
|
|
|
ext4_lock_group(sb, entry->efd_group);
|
|
|
|
/* Take it out of per group rb tree */
|
|
|
|
rb_erase(&entry->efd_node, &(db->bb_free_root));
|
|
|
|
mb_free_blocks(NULL, &e4b, entry->efd_start_cluster, entry->efd_count);
|
2008-10-16 14:14:27 +00:00
|
|
|
|
2012-02-20 22:53:02 +00:00
|
|
|
/*
|
|
|
|
* Clear the trimmed flag for the group so that the next
|
|
|
|
* ext4_trim_fs can trim it.
|
|
|
|
*/
|
2024-08-17 08:55:10 +00:00
|
|
|
EXT4_MB_GRP_CLEAR_TRIMMED(db);
|
2011-07-11 04:03:38 +00:00
|
|
|
|
2012-02-20 22:53:02 +00:00
|
|
|
if (!db->bb_free_root.rb_node) {
|
|
|
|
/* No more items in the per group rb tree
|
|
|
|
* balance refcounts from ext4_mb_free_metadata()
|
|
|
|
*/
|
2024-04-16 17:28:55 +00:00
|
|
|
folio_put(e4b.bd_buddy_folio);
|
2024-04-16 17:28:54 +00:00
|
|
|
folio_put(e4b.bd_bitmap_folio);
|
2008-10-17 00:00:24 +00:00
|
|
|
}
|
2012-02-20 22:53:02 +00:00
|
|
|
ext4_unlock_group(sb, entry->efd_group);
|
|
|
|
ext4_mb_unload_buddy(&e4b);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2023-03-03 17:21:16 +00:00
|
|
|
mb_debug(sb, "freed %d blocks in 1 structures\n", count);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
2017-06-23 03:54:33 +00:00
|
|
|
/*
|
|
|
|
* This function is called by the jbd2 layer once the commit has finished,
|
|
|
|
* so we know we can free the blocks that were released with that commit.
|
|
|
|
*/
|
|
|
|
void ext4_process_freed_data(struct super_block *sb, tid_t commit_tid)
|
|
|
|
{
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
|
|
|
struct ext4_free_data *entry, *tmp;
|
2023-08-12 07:18:39 +00:00
|
|
|
LIST_HEAD(freed_data_list);
|
2023-06-12 12:40:17 +00:00
|
|
|
struct list_head *s_freed_head = &sbi->s_freed_data_list[commit_tid & 1];
|
2021-07-24 07:41:23 +00:00
|
|
|
bool wake;
|
2017-06-23 03:54:33 +00:00
|
|
|
|
2023-06-12 12:40:17 +00:00
|
|
|
list_replace_init(s_freed_head, &freed_data_list);
|
2017-06-23 03:54:33 +00:00
|
|
|
|
2021-07-24 07:41:23 +00:00
|
|
|
list_for_each_entry(entry, &freed_data_list, efd_list)
|
|
|
|
ext4_free_data_in_buddy(sb, entry);
|
2017-06-23 03:54:33 +00:00
|
|
|
|
2021-07-24 07:41:23 +00:00
|
|
|
if (test_opt(sb, DISCARD)) {
|
|
|
|
spin_lock(&sbi->s_md_lock);
|
|
|
|
wake = list_empty(&sbi->s_discard_list);
|
|
|
|
list_splice_tail(&freed_data_list, &sbi->s_discard_list);
|
|
|
|
spin_unlock(&sbi->s_md_lock);
|
|
|
|
if (wake)
|
|
|
|
queue_work(system_unbound_wq, &sbi->s_discard_work);
|
|
|
|
} else {
|
|
|
|
list_for_each_entry_safe(entry, tmp, &freed_data_list, efd_list)
|
|
|
|
kmem_cache_free(ext4_free_data_cachep, entry);
|
2017-06-23 03:54:33 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-10-28 01:30:14 +00:00
|
|
|
int __init ext4_init_mballoc(void)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
2010-10-28 01:30:09 +00:00
|
|
|
ext4_pspace_cachep = KMEM_CACHE(ext4_prealloc_space,
|
|
|
|
SLAB_RECLAIM_ACCOUNT);
|
2008-01-29 05:19:52 +00:00
|
|
|
if (ext4_pspace_cachep == NULL)
|
2020-05-10 06:24:46 +00:00
|
|
|
goto out;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2010-10-28 01:30:09 +00:00
|
|
|
ext4_ac_cachep = KMEM_CACHE(ext4_allocation_context,
|
|
|
|
SLAB_RECLAIM_ACCOUNT);
|
2020-05-10 06:24:46 +00:00
|
|
|
if (ext4_ac_cachep == NULL)
|
|
|
|
goto out_pa_free;
|
2008-10-16 14:14:27 +00:00
|
|
|
|
2012-02-20 22:53:02 +00:00
|
|
|
ext4_free_data_cachep = KMEM_CACHE(ext4_free_data,
|
|
|
|
SLAB_RECLAIM_ACCOUNT);
|
2020-05-10 06:24:46 +00:00
|
|
|
if (ext4_free_data_cachep == NULL)
|
|
|
|
goto out_ac_free;
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
return 0;
|
2020-05-10 06:24:46 +00:00
|
|
|
|
|
|
|
out_ac_free:
|
|
|
|
kmem_cache_destroy(ext4_ac_cachep);
|
|
|
|
out_pa_free:
|
|
|
|
kmem_cache_destroy(ext4_pspace_cachep);
|
|
|
|
out:
|
|
|
|
return -ENOMEM;
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
2010-10-28 01:30:14 +00:00
|
|
|
void ext4_exit_mballoc(void)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
2010-05-17 11:00:00 +00:00
|
|
|
/*
|
2009-07-06 02:29:27 +00:00
|
|
|
* Wait for completion of call_rcu()'s on ext4_pspace_cachep
|
|
|
|
* before destroying the slab cache.
|
|
|
|
*/
|
|
|
|
rcu_barrier();
|
2008-01-29 05:19:52 +00:00
|
|
|
kmem_cache_destroy(ext4_pspace_cachep);
|
2008-02-10 06:13:33 +00:00
|
|
|
kmem_cache_destroy(ext4_ac_cachep);
|
2012-02-20 22:53:02 +00:00
|
|
|
kmem_cache_destroy(ext4_free_data_cachep);
|
2011-02-12 13:12:18 +00:00
|
|
|
ext4_groupinfo_destroy_slabs();
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
2023-09-28 16:03:59 +00:00
|
|
|
#define EXT4_MB_BITMAP_MARKED_CHECK 0x0001
|
|
|
|
#define EXT4_MB_SYNC_UPDATE 0x0002
|
2023-09-28 16:03:57 +00:00
|
|
|
static int
|
2023-09-28 16:03:59 +00:00
|
|
|
ext4_mb_mark_context(handle_t *handle, struct super_block *sb, bool state,
|
|
|
|
ext4_group_t group, ext4_grpblk_t blkoff,
|
|
|
|
ext4_grpblk_t len, int flags, ext4_grpblk_t *ret_changed)
|
2023-09-28 16:03:57 +00:00
|
|
|
{
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
|
|
|
struct buffer_head *bitmap_bh = NULL;
|
|
|
|
struct ext4_group_desc *gdp;
|
|
|
|
struct buffer_head *gdp_bh;
|
|
|
|
int err;
|
2023-09-28 16:03:59 +00:00
|
|
|
unsigned int i, already, changed = len;
|
2023-09-28 16:04:05 +00:00
|
|
|
|
|
|
|
KUNIT_STATIC_STUB_REDIRECT(ext4_mb_mark_context,
|
|
|
|
handle, sb, state, group, blkoff, len,
|
|
|
|
flags, ret_changed);
|
2023-09-28 16:03:57 +00:00
|
|
|
|
2023-09-28 16:03:59 +00:00
|
|
|
if (ret_changed)
|
|
|
|
*ret_changed = 0;
|
2023-09-28 16:03:57 +00:00
|
|
|
bitmap_bh = ext4_read_block_bitmap(sb, group);
|
|
|
|
if (IS_ERR(bitmap_bh))
|
|
|
|
return PTR_ERR(bitmap_bh);
|
|
|
|
|
2023-09-28 16:03:59 +00:00
|
|
|
if (handle) {
|
|
|
|
BUFFER_TRACE(bitmap_bh, "getting write access");
|
|
|
|
err = ext4_journal_get_write_access(handle, sb, bitmap_bh,
|
|
|
|
EXT4_JTR_NONE);
|
|
|
|
if (err)
|
|
|
|
goto out_err;
|
|
|
|
}
|
|
|
|
|
2023-09-28 16:03:57 +00:00
|
|
|
err = -EIO;
|
|
|
|
gdp = ext4_get_group_desc(sb, group, &gdp_bh);
|
|
|
|
if (!gdp)
|
|
|
|
goto out_err;
|
|
|
|
|
2023-09-28 16:03:59 +00:00
|
|
|
if (handle) {
|
|
|
|
BUFFER_TRACE(gdp_bh, "get_write_access");
|
|
|
|
err = ext4_journal_get_write_access(handle, sb, gdp_bh,
|
|
|
|
EXT4_JTR_NONE);
|
|
|
|
if (err)
|
|
|
|
goto out_err;
|
|
|
|
}
|
|
|
|
|
2023-09-28 16:03:57 +00:00
|
|
|
ext4_lock_group(sb, group);
|
|
|
|
if (ext4_has_group_desc_csum(sb) &&
|
|
|
|
(gdp->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT))) {
|
|
|
|
gdp->bg_flags &= cpu_to_le16(~EXT4_BG_BLOCK_UNINIT);
|
|
|
|
ext4_free_group_clusters_set(sb, gdp,
|
|
|
|
ext4_free_clusters_after_init(sb, group, gdp));
|
|
|
|
}
|
|
|
|
|
2023-09-28 16:03:59 +00:00
|
|
|
if (flags & EXT4_MB_BITMAP_MARKED_CHECK) {
|
|
|
|
already = 0;
|
|
|
|
for (i = 0; i < len; i++)
|
|
|
|
if (mb_test_bit(blkoff + i, bitmap_bh->b_data) ==
|
|
|
|
state)
|
|
|
|
already++;
|
|
|
|
changed = len - already;
|
|
|
|
}
|
2023-09-28 16:03:57 +00:00
|
|
|
|
|
|
|
if (state) {
|
|
|
|
mb_set_bits(bitmap_bh->b_data, blkoff, len);
|
|
|
|
ext4_free_group_clusters_set(sb, gdp,
|
|
|
|
ext4_free_group_clusters(sb, gdp) - changed);
|
|
|
|
} else {
|
|
|
|
mb_clear_bits(bitmap_bh->b_data, blkoff, len);
|
|
|
|
ext4_free_group_clusters_set(sb, gdp,
|
|
|
|
ext4_free_group_clusters(sb, gdp) + changed);
|
|
|
|
}
|
|
|
|
|
|
|
|
ext4_block_bitmap_csum_set(sb, gdp, bitmap_bh);
|
|
|
|
ext4_group_desc_csum_set(sb, group, gdp);
|
|
|
|
ext4_unlock_group(sb, group);
|
2023-09-28 16:03:59 +00:00
|
|
|
if (ret_changed)
|
|
|
|
*ret_changed = changed;
|
2023-09-28 16:03:57 +00:00
|
|
|
|
|
|
|
if (sbi->s_log_groups_per_flex) {
|
|
|
|
ext4_group_t flex_group = ext4_flex_group(sbi, group);
|
|
|
|
struct flex_groups *fg = sbi_array_rcu_deref(sbi,
|
|
|
|
s_flex_groups, flex_group);
|
|
|
|
|
|
|
|
if (state)
|
|
|
|
atomic64_sub(changed, &fg->free_clusters);
|
|
|
|
else
|
|
|
|
atomic64_add(changed, &fg->free_clusters);
|
|
|
|
}
|
|
|
|
|
2023-09-28 16:03:59 +00:00
|
|
|
err = ext4_handle_dirty_metadata(handle, NULL, bitmap_bh);
|
2023-09-28 16:03:57 +00:00
|
|
|
if (err)
|
|
|
|
goto out_err;
|
2023-09-28 16:03:59 +00:00
|
|
|
err = ext4_handle_dirty_metadata(handle, NULL, gdp_bh);
|
2023-09-28 16:03:57 +00:00
|
|
|
if (err)
|
|
|
|
goto out_err;
|
|
|
|
|
2023-09-28 16:03:59 +00:00
|
|
|
if (flags & EXT4_MB_SYNC_UPDATE) {
|
|
|
|
sync_dirty_buffer(bitmap_bh);
|
|
|
|
sync_dirty_buffer(gdp_bh);
|
|
|
|
}
|
2023-09-28 16:03:57 +00:00
|
|
|
|
|
|
|
out_err:
|
|
|
|
brelse(bitmap_bh);
|
|
|
|
return err;
|
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
/*
|
2010-07-30 19:02:47 +00:00
|
|
|
* Check quota and mark chosen space (ac->ac_b_ex) non-free in bitmaps
|
2008-01-29 05:19:52 +00:00
|
|
|
* Returns 0 if success or error code
|
|
|
|
*/
|
2008-04-29 12:11:12 +00:00
|
|
|
static noinline_for_stack int
|
|
|
|
ext4_mb_mark_diskspace_used(struct ext4_allocation_context *ac,
|
2011-09-09 22:48:51 +00:00
|
|
|
handle_t *handle, unsigned int reserv_clstrs)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
|
|
|
struct ext4_group_desc *gdp;
|
|
|
|
struct ext4_sb_info *sbi;
|
|
|
|
struct super_block *sb;
|
|
|
|
ext4_fsblk_t block;
|
2008-05-15 18:43:20 +00:00
|
|
|
int err, len;
|
2023-09-28 16:04:00 +00:00
|
|
|
int flags = 0;
|
|
|
|
ext4_grpblk_t changed;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
BUG_ON(ac->ac_status != AC_STATUS_FOUND);
|
|
|
|
BUG_ON(ac->ac_b_ex.fe_len <= 0);
|
|
|
|
|
|
|
|
sb = ac->ac_sb;
|
|
|
|
sbi = EXT4_SB(sb);
|
|
|
|
|
2023-09-28 16:04:00 +00:00
|
|
|
gdp = ext4_get_group_desc(sb, ac->ac_b_ex.fe_group, NULL);
|
2008-01-29 05:19:52 +00:00
|
|
|
if (!gdp)
|
2023-09-28 16:04:00 +00:00
|
|
|
return -EIO;
|
2009-01-06 03:18:16 +00:00
|
|
|
ext4_debug("using block group %u(%d)\n", ac->ac_b_ex.fe_group,
|
2011-09-09 23:08:51 +00:00
|
|
|
ext4_free_group_clusters(sb, gdp));
|
2008-06-06 00:59:29 +00:00
|
|
|
|
2010-03-04 04:53:25 +00:00
|
|
|
block = ext4_grp_offs_to_block(sb, &ac->ac_b_ex);
|
2011-09-09 22:48:51 +00:00
|
|
|
len = EXT4_C2B(sbi, ac->ac_b_ex.fe_len);
|
2020-07-28 13:04:34 +00:00
|
|
|
if (!ext4_inode_block_valid(ac->ac_inode, block, len)) {
|
2010-02-15 19:19:27 +00:00
|
|
|
ext4_error(sb, "Allocating blocks %llu-%llu which overlap "
|
2012-03-20 03:13:43 +00:00
|
|
|
"fs metadata", block, block+len);
|
2008-05-15 18:43:20 +00:00
|
|
|
/* File system mounted not to panic on error
|
2016-07-15 03:02:47 +00:00
|
|
|
* Fix the bitmap and return EFSCORRUPTED
|
2008-05-15 18:43:20 +00:00
|
|
|
* We leak some of the blocks here.
|
|
|
|
*/
|
2023-09-28 16:04:00 +00:00
|
|
|
err = ext4_mb_mark_context(handle, sb, true,
|
|
|
|
ac->ac_b_ex.fe_group,
|
|
|
|
ac->ac_b_ex.fe_start,
|
|
|
|
ac->ac_b_ex.fe_len,
|
|
|
|
0, NULL);
|
2008-05-15 18:43:20 +00:00
|
|
|
if (!err)
|
2016-07-15 03:02:47 +00:00
|
|
|
err = -EFSCORRUPTED;
|
2023-09-28 16:04:00 +00:00
|
|
|
return err;
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2009-05-03 00:35:09 +00:00
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
#ifdef AGGRESSIVE_CHECK
|
2023-09-28 16:04:00 +00:00
|
|
|
flags |= EXT4_MB_BITMAP_MARKED_CHECK;
|
2008-01-29 05:19:52 +00:00
|
|
|
#endif
|
2023-09-28 16:04:00 +00:00
|
|
|
err = ext4_mb_mark_context(handle, sb, true, ac->ac_b_ex.fe_group,
|
|
|
|
ac->ac_b_ex.fe_start, ac->ac_b_ex.fe_len,
|
|
|
|
flags, &changed);
|
|
|
|
|
|
|
|
if (err && changed == 0)
|
|
|
|
return err;
|
2009-05-03 00:35:09 +00:00
|
|
|
|
2023-09-28 16:04:00 +00:00
|
|
|
#ifdef AGGRESSIVE_CHECK
|
|
|
|
BUG_ON(changed != ac->ac_b_ex.fe_len);
|
|
|
|
#endif
|
2011-09-09 22:56:51 +00:00
|
|
|
percpu_counter_sub(&sbi->s_freeclusters_counter, ac->ac_b_ex.fe_len);
|
2008-07-14 21:52:37 +00:00
|
|
|
/*
|
2008-10-10 13:39:00 +00:00
|
|
|
* Now reduce the dirty block count also. Should not go negative
|
2008-07-14 21:52:37 +00:00
|
|
|
*/
|
2008-10-10 13:39:00 +00:00
|
|
|
if (!(ac->ac_flags & EXT4_MB_DELALLOC_RESERVED))
|
|
|
|
/* release all the reserved blocks if non delalloc */
|
2011-09-09 22:56:51 +00:00
|
|
|
percpu_counter_sub(&sbi->s_dirtyclusters_counter,
|
|
|
|
reserv_clstrs);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2020-10-15 20:37:59 +00:00
|
|
|
/*
|
|
|
|
* Idempotent helper for Ext4 fast commit replay path to set the state of
|
|
|
|
* blocks in bitmaps and update counters.
|
|
|
|
*/
|
|
|
|
void ext4_mb_mark_bb(struct super_block *sb, ext4_fsblk_t block,
|
2023-09-28 16:03:56 +00:00
|
|
|
int len, bool state)
|
2020-10-15 20:37:59 +00:00
|
|
|
{
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
|
|
|
ext4_group_t group;
|
|
|
|
ext4_grpblk_t blkoff;
|
2023-09-28 16:03:57 +00:00
|
|
|
int err = 0;
|
|
|
|
unsigned int clen, thisgrp_len;
|
2020-10-15 20:37:59 +00:00
|
|
|
|
2022-02-16 07:02:44 +00:00
|
|
|
while (len > 0) {
|
|
|
|
ext4_get_group_no_and_offset(sb, block, &group, &blkoff);
|
2020-10-15 20:37:59 +00:00
|
|
|
|
2022-02-16 07:02:44 +00:00
|
|
|
/*
|
|
|
|
* Check to see if we are freeing blocks across a group
|
|
|
|
* boundary.
|
|
|
|
* In case of flex_bg, this can happen that (block, len) may
|
|
|
|
* span across more than one group. In that case we need to
|
|
|
|
* get the corresponding group metadata to work with.
|
|
|
|
* For this we have goto again loop.
|
|
|
|
*/
|
|
|
|
thisgrp_len = min_t(unsigned int, (unsigned int)len,
|
|
|
|
EXT4_BLOCKS_PER_GROUP(sb) - EXT4_C2B(sbi, blkoff));
|
|
|
|
clen = EXT4_NUM_B2C(sbi, thisgrp_len);
|
|
|
|
|
2022-02-16 07:02:51 +00:00
|
|
|
if (!ext4_sb_block_valid(sb, NULL, block, thisgrp_len)) {
|
|
|
|
ext4_error(sb, "Marking blocks in system zone - "
|
|
|
|
"Block = %llu, len = %u",
|
|
|
|
block, thisgrp_len);
|
2022-02-16 07:02:44 +00:00
|
|
|
break;
|
|
|
|
}
|
2020-10-15 20:37:59 +00:00
|
|
|
|
2023-09-28 16:03:59 +00:00
|
|
|
err = ext4_mb_mark_context(NULL, sb, state,
|
|
|
|
group, blkoff, clen,
|
|
|
|
EXT4_MB_BITMAP_MARKED_CHECK |
|
|
|
|
EXT4_MB_SYNC_UPDATE,
|
|
|
|
NULL);
|
2022-02-16 07:02:44 +00:00
|
|
|
if (err)
|
|
|
|
break;
|
|
|
|
|
|
|
|
block += thisgrp_len;
|
|
|
|
len -= thisgrp_len;
|
|
|
|
BUG_ON(len < 0);
|
2020-10-15 20:37:59 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
/*
|
|
|
|
* here we normalize request for locality group
|
2011-07-18 01:11:30 +00:00
|
|
|
* Group request are normalized to s_mb_group_prealloc, which goes to
|
|
|
|
* s_strip if we set the same via mount option.
|
|
|
|
* s_mb_group_prealloc can be configured via
|
2009-03-31 13:11:14 +00:00
|
|
|
* /sys/fs/ext4/<partition>/mb_group_prealloc
|
2008-01-29 05:19:52 +00:00
|
|
|
*
|
|
|
|
* XXX: should we try to preallocate more than the group has now?
|
|
|
|
*/
|
|
|
|
static void ext4_mb_normalize_group_request(struct ext4_allocation_context *ac)
|
|
|
|
{
|
|
|
|
struct super_block *sb = ac->ac_sb;
|
|
|
|
struct ext4_locality_group *lg = ac->ac_lg;
|
|
|
|
|
|
|
|
BUG_ON(lg == NULL);
|
2011-07-18 01:11:30 +00:00
|
|
|
ac->ac_g_ex.fe_len = EXT4_SB(sb)->s_mb_group_prealloc;
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "goal %u blocks for locality group\n", ac->ac_g_ex.fe_len);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
/*
|
|
|
|
* This function returns the next element to look at during inode
|
|
|
|
* PA rbtree walk. We assume that we have held the inode PA rbtree lock
|
|
|
|
* (ei->i_prealloc_lock)
|
|
|
|
*
|
|
|
|
* new_start The start of the range we want to compare
|
|
|
|
* cur_start The existing start that we are comparing against
|
|
|
|
* node The node of the rb_tree
|
|
|
|
*/
|
|
|
|
static inline struct rb_node*
|
|
|
|
ext4_mb_pa_rb_next_iter(ext4_lblk_t new_start, ext4_lblk_t cur_start, struct rb_node *node)
|
|
|
|
{
|
|
|
|
if (new_start < cur_start)
|
|
|
|
return node->rb_left;
|
|
|
|
else
|
|
|
|
return node->rb_right;
|
|
|
|
}
|
|
|
|
|
2023-03-25 08:13:37 +00:00
|
|
|
static inline void
|
|
|
|
ext4_mb_pa_assert_overlap(struct ext4_allocation_context *ac,
|
2023-07-24 12:10:59 +00:00
|
|
|
ext4_lblk_t start, loff_t end)
|
2023-03-25 08:13:37 +00:00
|
|
|
{
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(ac->ac_sb);
|
|
|
|
struct ext4_inode_info *ei = EXT4_I(ac->ac_inode);
|
|
|
|
struct ext4_prealloc_space *tmp_pa;
|
2023-07-24 12:10:59 +00:00
|
|
|
ext4_lblk_t tmp_pa_start;
|
|
|
|
loff_t tmp_pa_end;
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
struct rb_node *iter;
|
2023-03-25 08:13:37 +00:00
|
|
|
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
read_lock(&ei->i_prealloc_lock);
|
|
|
|
for (iter = ei->i_prealloc_node.rb_node; iter;
|
|
|
|
iter = ext4_mb_pa_rb_next_iter(start, tmp_pa_start, iter)) {
|
|
|
|
tmp_pa = rb_entry(iter, struct ext4_prealloc_space,
|
|
|
|
pa_node.inode_node);
|
|
|
|
tmp_pa_start = tmp_pa->pa_lstart;
|
2023-07-24 12:10:59 +00:00
|
|
|
tmp_pa_end = pa_logical_end(sbi, tmp_pa);
|
2023-03-25 08:13:37 +00:00
|
|
|
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
spin_lock(&tmp_pa->pa_lock);
|
|
|
|
if (tmp_pa->pa_deleted == 0)
|
2023-03-25 08:13:37 +00:00
|
|
|
BUG_ON(!(start >= tmp_pa_end || end <= tmp_pa_start));
|
|
|
|
spin_unlock(&tmp_pa->pa_lock);
|
|
|
|
}
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
read_unlock(&ei->i_prealloc_lock);
|
2023-03-25 08:13:37 +00:00
|
|
|
}
|
|
|
|
|
2023-03-25 08:13:38 +00:00
|
|
|
/*
|
|
|
|
* Given an allocation context "ac" and a range "start", "end", check
|
|
|
|
* and adjust boundaries if the range overlaps with any of the existing
|
|
|
|
* preallocatoins stored in the corresponding inode of the allocation context.
|
|
|
|
*
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
* Parameters:
|
2023-03-25 08:13:38 +00:00
|
|
|
* ac allocation context
|
|
|
|
* start start of the new range
|
|
|
|
* end end of the new range
|
|
|
|
*/
|
|
|
|
static inline void
|
|
|
|
ext4_mb_pa_adjust_overlap(struct ext4_allocation_context *ac,
|
2023-07-24 12:10:59 +00:00
|
|
|
ext4_lblk_t *start, loff_t *end)
|
2023-03-25 08:13:38 +00:00
|
|
|
{
|
|
|
|
struct ext4_inode_info *ei = EXT4_I(ac->ac_inode);
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(ac->ac_sb);
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
struct ext4_prealloc_space *tmp_pa = NULL, *left_pa = NULL, *right_pa = NULL;
|
|
|
|
struct rb_node *iter;
|
2023-07-24 12:10:59 +00:00
|
|
|
ext4_lblk_t new_start, tmp_pa_start, right_pa_start = -1;
|
|
|
|
loff_t new_end, tmp_pa_end, left_pa_end = -1;
|
2023-03-25 08:13:38 +00:00
|
|
|
|
|
|
|
new_start = *start;
|
|
|
|
new_end = *end;
|
|
|
|
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
/*
|
|
|
|
* Adjust the normalized range so that it doesn't overlap with any
|
|
|
|
* existing preallocated blocks(PAs). Make sure to hold the rbtree lock
|
|
|
|
* so it doesn't change underneath us.
|
|
|
|
*/
|
|
|
|
read_lock(&ei->i_prealloc_lock);
|
|
|
|
|
|
|
|
/* Step 1: find any one immediate neighboring PA of the normalized range */
|
|
|
|
for (iter = ei->i_prealloc_node.rb_node; iter;
|
|
|
|
iter = ext4_mb_pa_rb_next_iter(ac->ac_o_ex.fe_logical,
|
|
|
|
tmp_pa_start, iter)) {
|
|
|
|
tmp_pa = rb_entry(iter, struct ext4_prealloc_space,
|
|
|
|
pa_node.inode_node);
|
2023-03-25 08:13:38 +00:00
|
|
|
tmp_pa_start = tmp_pa->pa_lstart;
|
2023-07-24 12:10:59 +00:00
|
|
|
tmp_pa_end = pa_logical_end(sbi, tmp_pa);
|
2023-03-25 08:13:38 +00:00
|
|
|
|
|
|
|
/* PA must not overlap original request */
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
spin_lock(&tmp_pa->pa_lock);
|
|
|
|
if (tmp_pa->pa_deleted == 0)
|
|
|
|
BUG_ON(!(ac->ac_o_ex.fe_logical >= tmp_pa_end ||
|
|
|
|
ac->ac_o_ex.fe_logical < tmp_pa_start));
|
|
|
|
spin_unlock(&tmp_pa->pa_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Step 2: check if the found PA is left or right neighbor and
|
|
|
|
* get the other neighbor
|
|
|
|
*/
|
|
|
|
if (tmp_pa) {
|
|
|
|
if (tmp_pa->pa_lstart < ac->ac_o_ex.fe_logical) {
|
|
|
|
struct rb_node *tmp;
|
|
|
|
|
|
|
|
left_pa = tmp_pa;
|
|
|
|
tmp = rb_next(&left_pa->pa_node.inode_node);
|
|
|
|
if (tmp) {
|
|
|
|
right_pa = rb_entry(tmp,
|
|
|
|
struct ext4_prealloc_space,
|
|
|
|
pa_node.inode_node);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
struct rb_node *tmp;
|
|
|
|
|
|
|
|
right_pa = tmp_pa;
|
|
|
|
tmp = rb_prev(&right_pa->pa_node.inode_node);
|
|
|
|
if (tmp) {
|
|
|
|
left_pa = rb_entry(tmp,
|
|
|
|
struct ext4_prealloc_space,
|
|
|
|
pa_node.inode_node);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Step 3: get the non deleted neighbors */
|
|
|
|
if (left_pa) {
|
|
|
|
for (iter = &left_pa->pa_node.inode_node;;
|
|
|
|
iter = rb_prev(iter)) {
|
|
|
|
if (!iter) {
|
|
|
|
left_pa = NULL;
|
|
|
|
break;
|
|
|
|
}
|
2023-03-25 08:13:38 +00:00
|
|
|
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
tmp_pa = rb_entry(iter, struct ext4_prealloc_space,
|
|
|
|
pa_node.inode_node);
|
|
|
|
left_pa = tmp_pa;
|
|
|
|
spin_lock(&tmp_pa->pa_lock);
|
|
|
|
if (tmp_pa->pa_deleted == 0) {
|
|
|
|
spin_unlock(&tmp_pa->pa_lock);
|
|
|
|
break;
|
|
|
|
}
|
2023-03-25 08:13:38 +00:00
|
|
|
spin_unlock(&tmp_pa->pa_lock);
|
|
|
|
}
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (right_pa) {
|
|
|
|
for (iter = &right_pa->pa_node.inode_node;;
|
|
|
|
iter = rb_next(iter)) {
|
|
|
|
if (!iter) {
|
|
|
|
right_pa = NULL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
tmp_pa = rb_entry(iter, struct ext4_prealloc_space,
|
|
|
|
pa_node.inode_node);
|
|
|
|
right_pa = tmp_pa;
|
|
|
|
spin_lock(&tmp_pa->pa_lock);
|
|
|
|
if (tmp_pa->pa_deleted == 0) {
|
|
|
|
spin_unlock(&tmp_pa->pa_lock);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
spin_unlock(&tmp_pa->pa_lock);
|
2023-03-25 08:13:38 +00:00
|
|
|
}
|
|
|
|
}
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
|
|
|
|
if (left_pa) {
|
2023-07-24 12:10:59 +00:00
|
|
|
left_pa_end = pa_logical_end(sbi, left_pa);
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
BUG_ON(left_pa_end > ac->ac_o_ex.fe_logical);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (right_pa) {
|
|
|
|
right_pa_start = right_pa->pa_lstart;
|
|
|
|
BUG_ON(right_pa_start <= ac->ac_o_ex.fe_logical);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Step 4: trim our normalized range to not overlap with the neighbors */
|
|
|
|
if (left_pa) {
|
|
|
|
if (left_pa_end > new_start)
|
|
|
|
new_start = left_pa_end;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (right_pa) {
|
|
|
|
if (right_pa_start < new_end)
|
|
|
|
new_end = right_pa_start;
|
|
|
|
}
|
|
|
|
read_unlock(&ei->i_prealloc_lock);
|
2023-03-25 08:13:38 +00:00
|
|
|
|
|
|
|
/* XXX: extra loop to check we really don't overlap preallocations */
|
|
|
|
ext4_mb_pa_assert_overlap(ac, new_start, new_end);
|
|
|
|
|
|
|
|
*start = new_start;
|
|
|
|
*end = new_end;
|
|
|
|
}
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
/*
|
|
|
|
* Normalization means making request better in terms of
|
|
|
|
* size and alignment
|
|
|
|
*/
|
2008-04-29 12:11:12 +00:00
|
|
|
static noinline_for_stack void
|
|
|
|
ext4_mb_normalize_request(struct ext4_allocation_context *ac,
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_allocation_request *ar)
|
|
|
|
{
|
2011-09-09 22:48:51 +00:00
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(ac->ac_sb);
|
2023-03-03 17:21:01 +00:00
|
|
|
struct ext4_super_block *es = sbi->s_es;
|
2008-01-29 05:19:52 +00:00
|
|
|
int bsbits, max;
|
2023-07-24 12:10:59 +00:00
|
|
|
loff_t size, start_off, end;
|
2012-02-20 22:53:03 +00:00
|
|
|
loff_t orig_size __maybe_unused;
|
2010-06-14 17:28:03 +00:00
|
|
|
ext4_lblk_t start;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
/* do normalize only data requests, metadata requests
|
|
|
|
do not need preallocation */
|
|
|
|
if (!(ac->ac_flags & EXT4_MB_HINT_DATA))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* sometime caller may want exact blocks */
|
|
|
|
if (unlikely(ac->ac_flags & EXT4_MB_HINT_GOAL_ONLY))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* caller may indicate that preallocation isn't
|
|
|
|
* required (it's a tail, for example) */
|
|
|
|
if (ac->ac_flags & EXT4_MB_HINT_NOPREALLOC)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (ac->ac_flags & EXT4_MB_HINT_GROUP_ALLOC) {
|
|
|
|
ext4_mb_normalize_group_request(ac);
|
|
|
|
return ;
|
|
|
|
}
|
|
|
|
|
|
|
|
bsbits = ac->ac_sb->s_blocksize_bits;
|
|
|
|
|
|
|
|
/* first, let's learn actual file size
|
|
|
|
* given current request is allocated */
|
2023-07-24 12:10:57 +00:00
|
|
|
size = extent_logical_end(sbi, &ac->ac_o_ex);
|
2008-01-29 05:19:52 +00:00
|
|
|
size = size << bsbits;
|
|
|
|
if (size < i_size_read(ac->ac_inode))
|
|
|
|
size = i_size_read(ac->ac_inode);
|
2010-06-14 17:28:03 +00:00
|
|
|
orig_size = size;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
ext4: mballoc fix mb_normalize_request algorithm for 1KB block size filesystems
In case of inode preallocation, the number of blocks to allocate depends
on the file size and it is calculated in ext4_mb_normalize_request().
Each group in the filesystem is then checked to find one that can be
used for allocation; this is done in ext4_mb_good_group().
When a file bigger than 4MB is created, the requested number of blocks
to preallocate, calculated by ext4_mb_normalize_request is 4096.
However for a filesystem with 1KB block size, the maximum size of the
block buddies used by the multiblock allocator is 2048, so none of
groups in the filesystem satisfies the search criteria in
ext4_mb_good_group(). Scanning all the filesystem groups impacts
performance.
This was demonstrated by using a freshly created, 70GB, 1k block
filesystem, with caches dropped write before the test via
/proc/sys/vm/drop_caches, and with the filesystem mounted with
nodelalloc and nodealloc,nomballoc. The time to write an 8 megabyte
file using "dd if=/dev/zero of=/mnt/test/fo bs=8k count=1k conv=fsync"
took 35.5091 seconds (236kB/s) with nodellaloc, and 0.233754 seconds
(35.9 MB/s) with the nodelloc,nomballoc options. With a 1TB partition,
it took several minutes to write 8MB!
This patch modifies the algorithm in ext4_mb_normalize_group_request to
calculate the number of blocks to allocate by taking into account the
maximum size of free blocks chunks handled by the multiblock allocator.
It has also been tested for filesystems with 2KB and 4KB block sizes to
ensure that those cases don't regress.
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Valerie Clement <valerie.clement@bull.net>
Signed-off-by: Mingming Cao <cmm@us.ibm.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2008-05-13 23:31:14 +00:00
|
|
|
/* max size of free chunks */
|
|
|
|
max = 2 << bsbits;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
ext4: mballoc fix mb_normalize_request algorithm for 1KB block size filesystems
In case of inode preallocation, the number of blocks to allocate depends
on the file size and it is calculated in ext4_mb_normalize_request().
Each group in the filesystem is then checked to find one that can be
used for allocation; this is done in ext4_mb_good_group().
When a file bigger than 4MB is created, the requested number of blocks
to preallocate, calculated by ext4_mb_normalize_request is 4096.
However for a filesystem with 1KB block size, the maximum size of the
block buddies used by the multiblock allocator is 2048, so none of
groups in the filesystem satisfies the search criteria in
ext4_mb_good_group(). Scanning all the filesystem groups impacts
performance.
This was demonstrated by using a freshly created, 70GB, 1k block
filesystem, with caches dropped write before the test via
/proc/sys/vm/drop_caches, and with the filesystem mounted with
nodelalloc and nodealloc,nomballoc. The time to write an 8 megabyte
file using "dd if=/dev/zero of=/mnt/test/fo bs=8k count=1k conv=fsync"
took 35.5091 seconds (236kB/s) with nodellaloc, and 0.233754 seconds
(35.9 MB/s) with the nodelloc,nomballoc options. With a 1TB partition,
it took several minutes to write 8MB!
This patch modifies the algorithm in ext4_mb_normalize_group_request to
calculate the number of blocks to allocate by taking into account the
maximum size of free blocks chunks handled by the multiblock allocator.
It has also been tested for filesystems with 2KB and 4KB block sizes to
ensure that those cases don't regress.
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Valerie Clement <valerie.clement@bull.net>
Signed-off-by: Mingming Cao <cmm@us.ibm.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2008-05-13 23:31:14 +00:00
|
|
|
#define NRL_CHECK_SIZE(req, size, max, chunk_size) \
|
|
|
|
(req <= (size) || max <= (chunk_size))
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
/* first, try to predict filesize */
|
|
|
|
/* XXX: should this table be tunable? */
|
|
|
|
start_off = 0;
|
|
|
|
if (size <= 16 * 1024) {
|
|
|
|
size = 16 * 1024;
|
|
|
|
} else if (size <= 32 * 1024) {
|
|
|
|
size = 32 * 1024;
|
|
|
|
} else if (size <= 64 * 1024) {
|
|
|
|
size = 64 * 1024;
|
|
|
|
} else if (size <= 128 * 1024) {
|
|
|
|
size = 128 * 1024;
|
|
|
|
} else if (size <= 256 * 1024) {
|
|
|
|
size = 256 * 1024;
|
|
|
|
} else if (size <= 512 * 1024) {
|
|
|
|
size = 512 * 1024;
|
|
|
|
} else if (size <= 1024 * 1024) {
|
|
|
|
size = 1024 * 1024;
|
ext4: mballoc fix mb_normalize_request algorithm for 1KB block size filesystems
In case of inode preallocation, the number of blocks to allocate depends
on the file size and it is calculated in ext4_mb_normalize_request().
Each group in the filesystem is then checked to find one that can be
used for allocation; this is done in ext4_mb_good_group().
When a file bigger than 4MB is created, the requested number of blocks
to preallocate, calculated by ext4_mb_normalize_request is 4096.
However for a filesystem with 1KB block size, the maximum size of the
block buddies used by the multiblock allocator is 2048, so none of
groups in the filesystem satisfies the search criteria in
ext4_mb_good_group(). Scanning all the filesystem groups impacts
performance.
This was demonstrated by using a freshly created, 70GB, 1k block
filesystem, with caches dropped write before the test via
/proc/sys/vm/drop_caches, and with the filesystem mounted with
nodelalloc and nodealloc,nomballoc. The time to write an 8 megabyte
file using "dd if=/dev/zero of=/mnt/test/fo bs=8k count=1k conv=fsync"
took 35.5091 seconds (236kB/s) with nodellaloc, and 0.233754 seconds
(35.9 MB/s) with the nodelloc,nomballoc options. With a 1TB partition,
it took several minutes to write 8MB!
This patch modifies the algorithm in ext4_mb_normalize_group_request to
calculate the number of blocks to allocate by taking into account the
maximum size of free blocks chunks handled by the multiblock allocator.
It has also been tested for filesystems with 2KB and 4KB block sizes to
ensure that those cases don't regress.
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Valerie Clement <valerie.clement@bull.net>
Signed-off-by: Mingming Cao <cmm@us.ibm.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2008-05-13 23:31:14 +00:00
|
|
|
} else if (NRL_CHECK_SIZE(size, 4 * 1024 * 1024, max, 2 * 1024)) {
|
2008-01-29 05:19:52 +00:00
|
|
|
start_off = ((loff_t)ac->ac_o_ex.fe_logical >>
|
ext4: mballoc fix mb_normalize_request algorithm for 1KB block size filesystems
In case of inode preallocation, the number of blocks to allocate depends
on the file size and it is calculated in ext4_mb_normalize_request().
Each group in the filesystem is then checked to find one that can be
used for allocation; this is done in ext4_mb_good_group().
When a file bigger than 4MB is created, the requested number of blocks
to preallocate, calculated by ext4_mb_normalize_request is 4096.
However for a filesystem with 1KB block size, the maximum size of the
block buddies used by the multiblock allocator is 2048, so none of
groups in the filesystem satisfies the search criteria in
ext4_mb_good_group(). Scanning all the filesystem groups impacts
performance.
This was demonstrated by using a freshly created, 70GB, 1k block
filesystem, with caches dropped write before the test via
/proc/sys/vm/drop_caches, and with the filesystem mounted with
nodelalloc and nodealloc,nomballoc. The time to write an 8 megabyte
file using "dd if=/dev/zero of=/mnt/test/fo bs=8k count=1k conv=fsync"
took 35.5091 seconds (236kB/s) with nodellaloc, and 0.233754 seconds
(35.9 MB/s) with the nodelloc,nomballoc options. With a 1TB partition,
it took several minutes to write 8MB!
This patch modifies the algorithm in ext4_mb_normalize_group_request to
calculate the number of blocks to allocate by taking into account the
maximum size of free blocks chunks handled by the multiblock allocator.
It has also been tested for filesystems with 2KB and 4KB block sizes to
ensure that those cases don't regress.
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Valerie Clement <valerie.clement@bull.net>
Signed-off-by: Mingming Cao <cmm@us.ibm.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2008-05-13 23:31:14 +00:00
|
|
|
(21 - bsbits)) << 21;
|
|
|
|
size = 2 * 1024 * 1024;
|
|
|
|
} else if (NRL_CHECK_SIZE(size, 8 * 1024 * 1024, max, 4 * 1024)) {
|
2008-01-29 05:19:52 +00:00
|
|
|
start_off = ((loff_t)ac->ac_o_ex.fe_logical >>
|
|
|
|
(22 - bsbits)) << 22;
|
|
|
|
size = 4 * 1024 * 1024;
|
2023-06-03 15:03:09 +00:00
|
|
|
} else if (NRL_CHECK_SIZE(EXT4_C2B(sbi, ac->ac_o_ex.fe_len),
|
ext4: mballoc fix mb_normalize_request algorithm for 1KB block size filesystems
In case of inode preallocation, the number of blocks to allocate depends
on the file size and it is calculated in ext4_mb_normalize_request().
Each group in the filesystem is then checked to find one that can be
used for allocation; this is done in ext4_mb_good_group().
When a file bigger than 4MB is created, the requested number of blocks
to preallocate, calculated by ext4_mb_normalize_request is 4096.
However for a filesystem with 1KB block size, the maximum size of the
block buddies used by the multiblock allocator is 2048, so none of
groups in the filesystem satisfies the search criteria in
ext4_mb_good_group(). Scanning all the filesystem groups impacts
performance.
This was demonstrated by using a freshly created, 70GB, 1k block
filesystem, with caches dropped write before the test via
/proc/sys/vm/drop_caches, and with the filesystem mounted with
nodelalloc and nodealloc,nomballoc. The time to write an 8 megabyte
file using "dd if=/dev/zero of=/mnt/test/fo bs=8k count=1k conv=fsync"
took 35.5091 seconds (236kB/s) with nodellaloc, and 0.233754 seconds
(35.9 MB/s) with the nodelloc,nomballoc options. With a 1TB partition,
it took several minutes to write 8MB!
This patch modifies the algorithm in ext4_mb_normalize_group_request to
calculate the number of blocks to allocate by taking into account the
maximum size of free blocks chunks handled by the multiblock allocator.
It has also been tested for filesystems with 2KB and 4KB block sizes to
ensure that those cases don't regress.
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Valerie Clement <valerie.clement@bull.net>
Signed-off-by: Mingming Cao <cmm@us.ibm.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2008-05-13 23:31:14 +00:00
|
|
|
(8<<20)>>bsbits, max, 8 * 1024)) {
|
2008-01-29 05:19:52 +00:00
|
|
|
start_off = ((loff_t)ac->ac_o_ex.fe_logical >>
|
|
|
|
(23 - bsbits)) << 23;
|
|
|
|
size = 8 * 1024 * 1024;
|
|
|
|
} else {
|
2014-07-28 02:26:36 +00:00
|
|
|
start_off = (loff_t) ac->ac_o_ex.fe_logical << bsbits;
|
2023-03-11 17:09:49 +00:00
|
|
|
size = (loff_t) EXT4_C2B(sbi,
|
2014-07-28 02:26:36 +00:00
|
|
|
ac->ac_o_ex.fe_len) << bsbits;
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2010-06-14 17:28:03 +00:00
|
|
|
size = size >> bsbits;
|
|
|
|
start = start_off >> bsbits;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2022-05-28 11:00:15 +00:00
|
|
|
/*
|
|
|
|
* For tiny groups (smaller than 8MB) the chosen allocation
|
|
|
|
* alignment may be larger than group size. Make sure the
|
|
|
|
* alignment does not move allocation to a different group which
|
|
|
|
* makes mballoc fail assertions later.
|
|
|
|
*/
|
|
|
|
start = max(start, rounddown(ac->ac_o_ex.fe_logical,
|
|
|
|
(ext4_lblk_t)EXT4_BLOCKS_PER_GROUP(ac->ac_sb)));
|
|
|
|
|
2023-11-27 06:33:13 +00:00
|
|
|
/* avoid unnecessary preallocation that may trigger assertions */
|
|
|
|
if (start + size > EXT_MAX_BLOCKS)
|
|
|
|
size = EXT_MAX_BLOCKS - start;
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
/* don't cover already allocated blocks in selected range */
|
|
|
|
if (ar->pleft && start <= ar->lleft) {
|
|
|
|
size -= ar->lleft + 1 - start;
|
|
|
|
start = ar->lleft + 1;
|
|
|
|
}
|
|
|
|
if (ar->pright && start + size - 1 >= ar->lright)
|
|
|
|
size -= start + size - ar->lright;
|
|
|
|
|
2017-01-27 19:34:30 +00:00
|
|
|
/*
|
|
|
|
* Trim allocation request for filesystems with artificially small
|
|
|
|
* groups.
|
|
|
|
*/
|
|
|
|
if (size > EXT4_BLOCKS_PER_GROUP(ac->ac_sb))
|
|
|
|
size = EXT4_BLOCKS_PER_GROUP(ac->ac_sb);
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
end = start + size;
|
|
|
|
|
2023-03-25 08:13:38 +00:00
|
|
|
ext4_mb_pa_adjust_overlap(ac, &start, &end);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
size = end - start;
|
|
|
|
|
2022-05-28 11:00:16 +00:00
|
|
|
/*
|
|
|
|
* In this function "start" and "size" are normalized for better
|
|
|
|
* alignment and length such that we could preallocate more blocks.
|
|
|
|
* This normalization is done such that original request of
|
|
|
|
* ac->ac_o_ex.fe_logical & fe_len should always lie within "start" and
|
|
|
|
* "size" boundaries.
|
|
|
|
* (Note fe_len can be relaxed since FS block allocation API does not
|
|
|
|
* provide gurantee on number of contiguous blocks allocation since that
|
|
|
|
* depends upon free space left, etc).
|
|
|
|
* In case of inode pa, later we use the allocated blocks
|
2023-03-11 17:09:48 +00:00
|
|
|
* [pa_pstart + fe_logical - pa_lstart, fe_len/size] from the preallocated
|
2022-05-28 11:00:16 +00:00
|
|
|
* range of goal/best blocks [start, size] to put it at the
|
|
|
|
* ac_o_ex.fe_logical extent of this inode.
|
|
|
|
* (See ext4_mb_use_inode_pa() for more details)
|
|
|
|
*/
|
|
|
|
if (start + size <= ac->ac_o_ex.fe_logical ||
|
2008-01-29 05:19:52 +00:00
|
|
|
start > ac->ac_o_ex.fe_logical) {
|
2011-08-01 21:41:35 +00:00
|
|
|
ext4_msg(ac->ac_sb, KERN_ERR,
|
|
|
|
"start %lu, size %lu, fe_logical %lu",
|
|
|
|
(unsigned long) start, (unsigned long) size,
|
|
|
|
(unsigned long) ac->ac_o_ex.fe_logical);
|
2014-10-02 02:26:17 +00:00
|
|
|
BUG();
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2014-05-27 16:48:56 +00:00
|
|
|
BUG_ON(size <= 0 || size > EXT4_BLOCKS_PER_GROUP(ac->ac_sb));
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
/* now prepare goal request */
|
|
|
|
|
|
|
|
/* XXX: is it better to align blocks WRT to logical
|
|
|
|
* placement or satisfy big request as is */
|
|
|
|
ac->ac_g_ex.fe_logical = start;
|
2011-09-09 22:48:51 +00:00
|
|
|
ac->ac_g_ex.fe_len = EXT4_NUM_B2C(sbi, size);
|
2023-05-30 12:33:49 +00:00
|
|
|
ac->ac_orig_goal_len = ac->ac_g_ex.fe_len;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
/* define goal start in order to merge */
|
2023-03-03 17:21:01 +00:00
|
|
|
if (ar->pright && (ar->lright == (start + size)) &&
|
|
|
|
ar->pright >= size &&
|
|
|
|
ar->pright - size >= le32_to_cpu(es->s_first_data_block)) {
|
2008-01-29 05:19:52 +00:00
|
|
|
/* merge to the right */
|
|
|
|
ext4_get_group_no_and_offset(ac->ac_sb, ar->pright - size,
|
2023-03-03 17:21:01 +00:00
|
|
|
&ac->ac_g_ex.fe_group,
|
|
|
|
&ac->ac_g_ex.fe_start);
|
2008-01-29 05:19:52 +00:00
|
|
|
ac->ac_flags |= EXT4_MB_HINT_TRY_GOAL;
|
|
|
|
}
|
2023-03-03 17:21:01 +00:00
|
|
|
if (ar->pleft && (ar->lleft + 1 == start) &&
|
|
|
|
ar->pleft + 1 < ext4_blocks_count(es)) {
|
2008-01-29 05:19:52 +00:00
|
|
|
/* merge to the left */
|
|
|
|
ext4_get_group_no_and_offset(ac->ac_sb, ar->pleft + 1,
|
2023-03-03 17:21:01 +00:00
|
|
|
&ac->ac_g_ex.fe_group,
|
|
|
|
&ac->ac_g_ex.fe_start);
|
2008-01-29 05:19:52 +00:00
|
|
|
ac->ac_flags |= EXT4_MB_HINT_TRY_GOAL;
|
|
|
|
}
|
|
|
|
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(ac->ac_sb, "goal: %lld(was %lld) blocks at %u\n", size,
|
|
|
|
orig_size, start);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void ext4_mb_collect_stats(struct ext4_allocation_context *ac)
|
|
|
|
{
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(ac->ac_sb);
|
|
|
|
|
2021-04-01 17:21:25 +00:00
|
|
|
if (sbi->s_mb_stats && ac->ac_g_ex.fe_len >= 1) {
|
2008-01-29 05:19:52 +00:00
|
|
|
atomic_inc(&sbi->s_bal_reqs);
|
|
|
|
atomic_add(ac->ac_b_ex.fe_len, &sbi->s_bal_allocated);
|
2010-05-16 20:00:00 +00:00
|
|
|
if (ac->ac_b_ex.fe_len >= ac->ac_o_ex.fe_len)
|
2008-01-29 05:19:52 +00:00
|
|
|
atomic_inc(&sbi->s_bal_success);
|
2023-05-30 12:33:43 +00:00
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
atomic_add(ac->ac_found, &sbi->s_bal_ex_scanned);
|
2023-05-30 12:33:43 +00:00
|
|
|
for (int i=0; i<EXT4_MB_NUM_CRS; i++) {
|
|
|
|
atomic_add(ac->ac_cX_found[i], &sbi->s_bal_cX_ex_scanned[i]);
|
|
|
|
}
|
|
|
|
|
2021-04-01 17:21:25 +00:00
|
|
|
atomic_add(ac->ac_groups_scanned, &sbi->s_bal_groups_scanned);
|
2008-01-29 05:19:52 +00:00
|
|
|
if (ac->ac_g_ex.fe_start == ac->ac_b_ex.fe_start &&
|
|
|
|
ac->ac_g_ex.fe_group == ac->ac_b_ex.fe_group)
|
|
|
|
atomic_inc(&sbi->s_bal_goals);
|
2023-05-30 12:33:49 +00:00
|
|
|
/* did we allocate as much as normalizer originally wanted? */
|
|
|
|
if (ac->ac_f_ex.fe_len == ac->ac_orig_goal_len)
|
2023-05-30 12:33:44 +00:00
|
|
|
atomic_inc(&sbi->s_bal_len_goals);
|
2023-05-30 12:33:49 +00:00
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
if (ac->ac_found > sbi->s_mb_max_to_scan)
|
|
|
|
atomic_inc(&sbi->s_bal_breaks);
|
|
|
|
}
|
|
|
|
|
2009-09-30 04:32:42 +00:00
|
|
|
if (ac->ac_op == EXT4_MB_HISTORY_ALLOC)
|
|
|
|
trace_ext4_mballoc_alloc(ac);
|
|
|
|
else
|
|
|
|
trace_ext4_mballoc_prealloc(ac);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
2009-12-09 03:18:25 +00:00
|
|
|
/*
|
|
|
|
* Called on failure; free up any blocks from the inode PA for this
|
|
|
|
* context. We don't need this for MB_GROUP_PA because we only change
|
|
|
|
* pa_free in ext4_mb_release_context(), but on failure, we've already
|
|
|
|
* zeroed out ac->ac_b_ex.fe_len, so group_pa->pa_free is not changed.
|
|
|
|
*/
|
|
|
|
static void ext4_discard_allocated_blocks(struct ext4_allocation_context *ac)
|
|
|
|
{
|
|
|
|
struct ext4_prealloc_space *pa = ac->ac_pa;
|
2014-07-31 02:17:17 +00:00
|
|
|
struct ext4_buddy e4b;
|
|
|
|
int err;
|
2009-12-09 03:18:25 +00:00
|
|
|
|
2014-07-31 02:17:17 +00:00
|
|
|
if (pa == NULL) {
|
2014-08-23 21:47:28 +00:00
|
|
|
if (ac->ac_f_ex.fe_len == 0)
|
|
|
|
return;
|
2014-07-31 02:17:17 +00:00
|
|
|
err = ext4_mb_load_buddy(ac->ac_sb, ac->ac_f_ex.fe_group, &e4b);
|
2023-03-16 21:07:32 +00:00
|
|
|
if (WARN_RATELIMIT(err,
|
|
|
|
"ext4: mb_load_buddy failed (%d)", err))
|
2014-07-31 02:17:17 +00:00
|
|
|
/*
|
|
|
|
* This should never happen since we pin the
|
|
|
|
* pages in the ext4_allocation_context so
|
|
|
|
* ext4_mb_load_buddy() should never fail.
|
|
|
|
*/
|
|
|
|
return;
|
|
|
|
ext4_lock_group(ac->ac_sb, ac->ac_f_ex.fe_group);
|
|
|
|
mb_free_blocks(ac->ac_inode, &e4b, ac->ac_f_ex.fe_start,
|
|
|
|
ac->ac_f_ex.fe_len);
|
|
|
|
ext4_unlock_group(ac->ac_sb, ac->ac_f_ex.fe_group);
|
2014-08-23 21:47:28 +00:00
|
|
|
ext4_mb_unload_buddy(&e4b);
|
2014-07-31 02:17:17 +00:00
|
|
|
return;
|
|
|
|
}
|
2023-03-03 17:21:06 +00:00
|
|
|
if (pa->pa_type == MB_INODE_PA) {
|
|
|
|
spin_lock(&pa->pa_lock);
|
2012-05-28 21:53:53 +00:00
|
|
|
pa->pa_free += ac->ac_b_ex.fe_len;
|
2023-03-03 17:21:06 +00:00
|
|
|
spin_unlock(&pa->pa_lock);
|
|
|
|
}
|
2009-12-09 03:18:25 +00:00
|
|
|
}
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
/*
|
|
|
|
* use blocks preallocated to inode
|
|
|
|
*/
|
|
|
|
static void ext4_mb_use_inode_pa(struct ext4_allocation_context *ac,
|
|
|
|
struct ext4_prealloc_space *pa)
|
|
|
|
{
|
2011-09-09 22:48:51 +00:00
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(ac->ac_sb);
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_fsblk_t start;
|
|
|
|
ext4_fsblk_t end;
|
|
|
|
int len;
|
|
|
|
|
|
|
|
/* found preallocated blocks, use them */
|
|
|
|
start = pa->pa_pstart + (ac->ac_o_ex.fe_logical - pa->pa_lstart);
|
2011-09-09 22:48:51 +00:00
|
|
|
end = min(pa->pa_pstart + EXT4_C2B(sbi, pa->pa_len),
|
|
|
|
start + EXT4_C2B(sbi, ac->ac_o_ex.fe_len));
|
|
|
|
len = EXT4_NUM_B2C(sbi, end - start);
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_get_group_no_and_offset(ac->ac_sb, start, &ac->ac_b_ex.fe_group,
|
|
|
|
&ac->ac_b_ex.fe_start);
|
|
|
|
ac->ac_b_ex.fe_len = len;
|
|
|
|
ac->ac_status = AC_STATUS_FOUND;
|
|
|
|
ac->ac_pa = pa;
|
|
|
|
|
|
|
|
BUG_ON(start < pa->pa_pstart);
|
2011-09-09 22:48:51 +00:00
|
|
|
BUG_ON(end > pa->pa_pstart + EXT4_C2B(sbi, pa->pa_len));
|
2008-01-29 05:19:52 +00:00
|
|
|
BUG_ON(pa->pa_free < len);
|
2023-03-25 08:13:39 +00:00
|
|
|
BUG_ON(ac->ac_b_ex.fe_len <= 0);
|
2008-01-29 05:19:52 +00:00
|
|
|
pa->pa_free -= len;
|
|
|
|
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(ac->ac_sb, "use %llu/%d from inode pa %p\n", start, len, pa);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* use blocks preallocated to locality group
|
|
|
|
*/
|
|
|
|
static void ext4_mb_use_group_pa(struct ext4_allocation_context *ac,
|
|
|
|
struct ext4_prealloc_space *pa)
|
|
|
|
{
|
2008-06-06 00:59:29 +00:00
|
|
|
unsigned int len = ac->ac_o_ex.fe_len;
|
2008-07-23 18:14:05 +00:00
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_get_group_no_and_offset(ac->ac_sb, pa->pa_pstart,
|
|
|
|
&ac->ac_b_ex.fe_group,
|
|
|
|
&ac->ac_b_ex.fe_start);
|
|
|
|
ac->ac_b_ex.fe_len = len;
|
|
|
|
ac->ac_status = AC_STATUS_FOUND;
|
|
|
|
ac->ac_pa = pa;
|
|
|
|
|
2023-03-11 17:09:48 +00:00
|
|
|
/* we don't correct pa_pstart or pa_len here to avoid
|
2008-02-10 06:10:04 +00:00
|
|
|
* possible race when the group is being loaded concurrently
|
2008-01-29 05:19:52 +00:00
|
|
|
* instead we correct pa later, after blocks are marked
|
2008-02-10 06:10:04 +00:00
|
|
|
* in on-disk bitmap -- see ext4_mb_release_context()
|
|
|
|
* Other CPUs are prevented from allocating from this pa by lg_mutex
|
2008-01-29 05:19:52 +00:00
|
|
|
*/
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(ac->ac_sb, "use %u/%u from group pa %p\n",
|
2023-03-03 17:21:05 +00:00
|
|
|
pa->pa_lstart, len, pa);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
2008-08-18 22:00:57 +00:00
|
|
|
/*
|
|
|
|
* Return the prealloc space that have minimal distance
|
|
|
|
* from the goal block. @cpa is the prealloc
|
|
|
|
* space that is having currently known minimal distance
|
|
|
|
* from the goal block.
|
|
|
|
*/
|
|
|
|
static struct ext4_prealloc_space *
|
|
|
|
ext4_mb_check_group_pa(ext4_fsblk_t goal_block,
|
|
|
|
struct ext4_prealloc_space *pa,
|
|
|
|
struct ext4_prealloc_space *cpa)
|
|
|
|
{
|
|
|
|
ext4_fsblk_t cur_distance, new_distance;
|
|
|
|
|
|
|
|
if (cpa == NULL) {
|
|
|
|
atomic_inc(&pa->pa_count);
|
|
|
|
return pa;
|
|
|
|
}
|
2015-11-09 22:58:13 +00:00
|
|
|
cur_distance = abs(goal_block - cpa->pa_pstart);
|
|
|
|
new_distance = abs(goal_block - pa->pa_pstart);
|
2008-08-18 22:00:57 +00:00
|
|
|
|
2011-02-24 19:10:05 +00:00
|
|
|
if (cur_distance <= new_distance)
|
2008-08-18 22:00:57 +00:00
|
|
|
return cpa;
|
|
|
|
|
|
|
|
/* drop the previous reference */
|
|
|
|
atomic_dec(&cpa->pa_count);
|
|
|
|
atomic_inc(&pa->pa_count);
|
|
|
|
return pa;
|
|
|
|
}
|
|
|
|
|
2023-06-03 15:03:13 +00:00
|
|
|
/*
|
|
|
|
* check if found pa meets EXT4_MB_HINT_GOAL_ONLY
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
ext4_mb_pa_goal_check(struct ext4_allocation_context *ac,
|
|
|
|
struct ext4_prealloc_space *pa)
|
|
|
|
{
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(ac->ac_sb);
|
|
|
|
ext4_fsblk_t start;
|
|
|
|
|
|
|
|
if (likely(!(ac->ac_flags & EXT4_MB_HINT_GOAL_ONLY)))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If EXT4_MB_HINT_GOAL_ONLY is set, ac_g_ex will not be adjusted
|
|
|
|
* in ext4_mb_normalize_request and will keep same with ac_o_ex
|
|
|
|
* from ext4_mb_initialize_context. Choose ac_g_ex here to keep
|
|
|
|
* consistent with ext4_mb_find_by_goal.
|
|
|
|
*/
|
|
|
|
start = pa->pa_pstart +
|
|
|
|
(ac->ac_g_ex.fe_logical - pa->pa_lstart);
|
|
|
|
if (ext4_grp_offs_to_block(ac->ac_sb, &ac->ac_g_ex) != start)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (ac->ac_g_ex.fe_len > pa->pa_len -
|
|
|
|
EXT4_B2C(sbi, ac->ac_g_ex.fe_logical - pa->pa_lstart))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
/*
|
|
|
|
* search goal blocks in preallocated space
|
|
|
|
*/
|
2020-05-10 06:24:47 +00:00
|
|
|
static noinline_for_stack bool
|
2008-04-29 12:11:12 +00:00
|
|
|
ext4_mb_use_preallocated(struct ext4_allocation_context *ac)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
2011-09-09 22:48:51 +00:00
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(ac->ac_sb);
|
2008-07-23 18:14:05 +00:00
|
|
|
int order, i;
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_inode_info *ei = EXT4_I(ac->ac_inode);
|
|
|
|
struct ext4_locality_group *lg;
|
2023-07-22 17:15:24 +00:00
|
|
|
struct ext4_prealloc_space *tmp_pa = NULL, *cpa = NULL;
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
struct rb_node *iter;
|
2008-08-18 22:00:57 +00:00
|
|
|
ext4_fsblk_t goal_block;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
/* only data can be preallocated */
|
|
|
|
if (!(ac->ac_flags & EXT4_MB_HINT_DATA))
|
2020-05-10 06:24:47 +00:00
|
|
|
return false;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2023-07-22 17:15:24 +00:00
|
|
|
/*
|
|
|
|
* first, try per-file preallocation by searching the inode pa rbtree.
|
|
|
|
*
|
|
|
|
* Here, we can't do a direct traversal of the tree because
|
|
|
|
* ext4_mb_discard_group_preallocation() can paralelly mark the pa
|
|
|
|
* deleted and that can cause direct traversal to skip some entries.
|
|
|
|
*/
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
read_lock(&ei->i_prealloc_lock);
|
2023-07-22 17:15:24 +00:00
|
|
|
|
|
|
|
if (RB_EMPTY_ROOT(&ei->i_prealloc_node)) {
|
|
|
|
goto try_group_pa;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Step 1: Find a pa with logical start immediately adjacent to the
|
|
|
|
* original logical start. This could be on the left or right.
|
|
|
|
*
|
|
|
|
* (tmp_pa->pa_lstart never changes so we can skip locking for it).
|
|
|
|
*/
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
for (iter = ei->i_prealloc_node.rb_node; iter;
|
|
|
|
iter = ext4_mb_pa_rb_next_iter(ac->ac_o_ex.fe_logical,
|
2023-07-22 17:15:24 +00:00
|
|
|
tmp_pa->pa_lstart, iter)) {
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
tmp_pa = rb_entry(iter, struct ext4_prealloc_space,
|
|
|
|
pa_node.inode_node);
|
2023-07-22 17:15:24 +00:00
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2023-07-22 17:15:24 +00:00
|
|
|
/*
|
|
|
|
* Step 2: The adjacent pa might be to the right of logical start, find
|
|
|
|
* the left adjacent pa. After this step we'd have a valid tmp_pa whose
|
|
|
|
* logical start is towards the left of original request's logical start
|
|
|
|
*/
|
|
|
|
if (tmp_pa->pa_lstart > ac->ac_o_ex.fe_logical) {
|
|
|
|
struct rb_node *tmp;
|
|
|
|
tmp = rb_prev(&tmp_pa->pa_node.inode_node);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2023-07-22 17:15:24 +00:00
|
|
|
if (tmp) {
|
|
|
|
tmp_pa = rb_entry(tmp, struct ext4_prealloc_space,
|
|
|
|
pa_node.inode_node);
|
|
|
|
} else {
|
2023-03-25 08:13:34 +00:00
|
|
|
/*
|
2023-07-22 17:15:24 +00:00
|
|
|
* If there is no adjacent pa to the left then finding
|
|
|
|
* an overlapping pa is not possible hence stop searching
|
|
|
|
* inode pa tree
|
2023-03-25 08:13:34 +00:00
|
|
|
*/
|
2023-07-22 17:15:24 +00:00
|
|
|
goto try_group_pa;
|
2023-03-25 08:13:34 +00:00
|
|
|
}
|
2023-07-22 17:15:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
BUG_ON(!(tmp_pa && tmp_pa->pa_lstart <= ac->ac_o_ex.fe_logical));
|
ext4: limit block allocations for indirect-block files to < 2^32
Today, the ext4 allocator will happily allocate blocks past
2^32 for indirect-block files, which results in the block
numbers getting truncated, and corruption ensues.
This patch limits such allocations to < 2^32, and adds
BUG_ONs if we do get blocks larger than that.
This should address RH Bug 519471, ext4 bitmap allocator
must limit blocks to < 2^32
* ext4_find_goal() is modified to choose a goal < UINT_MAX,
so that our starting point is in an acceptable range.
* ext4_xattr_block_set() is modified such that the goal block
is < UINT_MAX, as above.
* ext4_mb_regular_allocator() is modified so that the group
search does not continue into groups which are too high
* ext4_mb_use_preallocated() has a check that we don't use
preallocated space which is too far out
* ext4_alloc_blocks() and ext4_xattr_block_set() add some BUG_ONs
No attempt has been made to limit inode locations to < 2^32,
so we may wind up with blocks far from their inodes. Doing
this much already will lead to some odd ENOSPC issues when the
"lower 32" gets full, and further restricting inodes could
make that even weirder.
For high inodes, choosing a goal of the original, % UINT_MAX,
may be a bit odd, but then we're in an odd situation anyway,
and I don't know of a better heuristic.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2009-09-16 18:45:10 +00:00
|
|
|
|
2023-07-22 17:15:24 +00:00
|
|
|
/*
|
|
|
|
* Step 3: If the left adjacent pa is deleted, keep moving left to find
|
|
|
|
* the first non deleted adjacent pa. After this step we should have a
|
|
|
|
* valid tmp_pa which is guaranteed to be non deleted.
|
|
|
|
*/
|
|
|
|
for (iter = &tmp_pa->pa_node.inode_node;; iter = rb_prev(iter)) {
|
|
|
|
if (!iter) {
|
|
|
|
/*
|
|
|
|
* no non deleted left adjacent pa, so stop searching
|
|
|
|
* inode pa tree
|
|
|
|
*/
|
|
|
|
goto try_group_pa;
|
|
|
|
}
|
|
|
|
tmp_pa = rb_entry(iter, struct ext4_prealloc_space,
|
|
|
|
pa_node.inode_node);
|
2023-03-25 08:13:36 +00:00
|
|
|
spin_lock(&tmp_pa->pa_lock);
|
2023-07-22 17:15:24 +00:00
|
|
|
if (tmp_pa->pa_deleted == 0) {
|
|
|
|
/*
|
|
|
|
* We will keep holding the pa_lock from
|
|
|
|
* this point on because we don't want group discard
|
|
|
|
* to delete this pa underneath us. Since group
|
|
|
|
* discard is anyways an ENOSPC operation it
|
|
|
|
* should be okay for it to wait a few more cycles.
|
|
|
|
*/
|
|
|
|
break;
|
|
|
|
} else {
|
2023-03-25 08:13:36 +00:00
|
|
|
spin_unlock(&tmp_pa->pa_lock);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2023-07-22 17:15:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
BUG_ON(!(tmp_pa && tmp_pa->pa_lstart <= ac->ac_o_ex.fe_logical));
|
|
|
|
BUG_ON(tmp_pa->pa_deleted == 1);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Step 4: We now have the non deleted left adjacent pa. Only this
|
|
|
|
* pa can possibly satisfy the request hence check if it overlaps
|
|
|
|
* original logical start and stop searching if it doesn't.
|
|
|
|
*/
|
2023-07-24 12:10:57 +00:00
|
|
|
if (ac->ac_o_ex.fe_logical >= pa_logical_end(sbi, tmp_pa)) {
|
2023-03-25 08:13:36 +00:00
|
|
|
spin_unlock(&tmp_pa->pa_lock);
|
2023-07-22 17:15:24 +00:00
|
|
|
goto try_group_pa;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* non-extent files can't have physical blocks past 2^32 */
|
|
|
|
if (!(ext4_test_inode_flag(ac->ac_inode, EXT4_INODE_EXTENTS)) &&
|
|
|
|
(tmp_pa->pa_pstart + EXT4_C2B(sbi, tmp_pa->pa_len) >
|
|
|
|
EXT4_MAX_BLOCK_FILE_PHYS)) {
|
|
|
|
/*
|
|
|
|
* Since PAs don't overlap, we won't find any other PA to
|
|
|
|
* satisfy this.
|
|
|
|
*/
|
|
|
|
spin_unlock(&tmp_pa->pa_lock);
|
|
|
|
goto try_group_pa;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (tmp_pa->pa_free && likely(ext4_mb_pa_goal_check(ac, tmp_pa))) {
|
|
|
|
atomic_inc(&tmp_pa->pa_count);
|
|
|
|
ext4_mb_use_inode_pa(ac, tmp_pa);
|
|
|
|
spin_unlock(&tmp_pa->pa_lock);
|
|
|
|
read_unlock(&ei->i_prealloc_lock);
|
|
|
|
return true;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* We found a valid overlapping pa but couldn't use it because
|
|
|
|
* it had no free blocks. This should ideally never happen
|
|
|
|
* because:
|
|
|
|
*
|
|
|
|
* 1. When a new inode pa is added to rbtree it must have
|
|
|
|
* pa_free > 0 since otherwise we won't actually need
|
|
|
|
* preallocation.
|
|
|
|
*
|
|
|
|
* 2. An inode pa that is in the rbtree can only have it's
|
|
|
|
* pa_free become zero when another thread calls:
|
|
|
|
* ext4_mb_new_blocks
|
|
|
|
* ext4_mb_use_preallocated
|
|
|
|
* ext4_mb_use_inode_pa
|
|
|
|
*
|
|
|
|
* 3. Further, after the above calls make pa_free == 0, we will
|
|
|
|
* immediately remove it from the rbtree in:
|
|
|
|
* ext4_mb_new_blocks
|
|
|
|
* ext4_mb_release_context
|
|
|
|
* ext4_mb_put_pa
|
|
|
|
*
|
|
|
|
* 4. Since the pa_free becoming 0 and pa_free getting removed
|
|
|
|
* from tree both happen in ext4_mb_new_blocks, which is always
|
|
|
|
* called with i_data_sem held for data allocations, we can be
|
|
|
|
* sure that another process will never see a pa in rbtree with
|
|
|
|
* pa_free == 0.
|
|
|
|
*/
|
|
|
|
WARN_ON_ONCE(tmp_pa->pa_free == 0);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2023-07-22 17:15:24 +00:00
|
|
|
spin_unlock(&tmp_pa->pa_lock);
|
|
|
|
try_group_pa:
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
read_unlock(&ei->i_prealloc_lock);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
/* can we use group allocation? */
|
|
|
|
if (!(ac->ac_flags & EXT4_MB_HINT_GROUP_ALLOC))
|
2020-05-10 06:24:47 +00:00
|
|
|
return false;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
/* inode may have no locality group for some reason */
|
|
|
|
lg = ac->ac_lg;
|
|
|
|
if (lg == NULL)
|
2020-05-10 06:24:47 +00:00
|
|
|
return false;
|
2008-07-23 18:14:05 +00:00
|
|
|
order = fls(ac->ac_o_ex.fe_len) - 1;
|
|
|
|
if (order > PREALLOC_TB_SIZE - 1)
|
|
|
|
/* The max size of hash table is PREALLOC_TB_SIZE */
|
|
|
|
order = PREALLOC_TB_SIZE - 1;
|
|
|
|
|
2010-03-04 04:53:25 +00:00
|
|
|
goal_block = ext4_grp_offs_to_block(ac->ac_sb, &ac->ac_g_ex);
|
2008-08-18 22:00:57 +00:00
|
|
|
/*
|
|
|
|
* search for the prealloc space that is having
|
|
|
|
* minimal distance from the goal block.
|
|
|
|
*/
|
2008-07-23 18:14:05 +00:00
|
|
|
for (i = order; i < PREALLOC_TB_SIZE; i++) {
|
|
|
|
rcu_read_lock();
|
2023-03-25 08:13:36 +00:00
|
|
|
list_for_each_entry_rcu(tmp_pa, &lg->lg_prealloc_list[i],
|
2023-03-25 08:13:40 +00:00
|
|
|
pa_node.lg_list) {
|
2023-03-25 08:13:36 +00:00
|
|
|
spin_lock(&tmp_pa->pa_lock);
|
|
|
|
if (tmp_pa->pa_deleted == 0 &&
|
|
|
|
tmp_pa->pa_free >= ac->ac_o_ex.fe_len) {
|
2008-08-18 22:00:57 +00:00
|
|
|
|
|
|
|
cpa = ext4_mb_check_group_pa(goal_block,
|
2023-03-25 08:13:36 +00:00
|
|
|
tmp_pa, cpa);
|
2008-07-23 18:14:05 +00:00
|
|
|
}
|
2023-03-25 08:13:36 +00:00
|
|
|
spin_unlock(&tmp_pa->pa_lock);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2008-07-23 18:14:05 +00:00
|
|
|
rcu_read_unlock();
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2008-08-18 22:00:57 +00:00
|
|
|
if (cpa) {
|
|
|
|
ext4_mb_use_group_pa(ac, cpa);
|
2020-05-10 06:24:47 +00:00
|
|
|
return true;
|
2008-08-18 22:00:57 +00:00
|
|
|
}
|
2020-05-10 06:24:47 +00:00
|
|
|
return false;
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* the function goes through all preallocation in this group and marks them
|
|
|
|
* used in in-core bitmap. buddy must be generated from this bitmap
|
2009-05-03 00:35:09 +00:00
|
|
|
* Need to be called with ext4 group lock held
|
2008-01-29 05:19:52 +00:00
|
|
|
*/
|
2009-07-06 02:17:31 +00:00
|
|
|
static noinline_for_stack
|
|
|
|
void ext4_mb_generate_from_pa(struct super_block *sb, void *bitmap,
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_group_t group)
|
|
|
|
{
|
|
|
|
struct ext4_group_info *grp = ext4_get_group_info(sb, group);
|
|
|
|
struct ext4_prealloc_space *pa;
|
|
|
|
struct list_head *cur;
|
|
|
|
ext4_group_t groupnr;
|
|
|
|
ext4_grpblk_t start;
|
|
|
|
int preallocated = 0;
|
|
|
|
int len;
|
|
|
|
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
if (!grp)
|
|
|
|
return;
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
/* all form of preallocation discards first load group,
|
|
|
|
* so the only competing code is preallocation use.
|
|
|
|
* we don't need any locking here
|
|
|
|
* notice we do NOT ignore preallocations with pa_deleted
|
|
|
|
* otherwise we could leave used blocks available for
|
|
|
|
* allocation in buddy when concurrent ext4_mb_put_pa()
|
|
|
|
* is dropping preallocation
|
|
|
|
*/
|
|
|
|
list_for_each(cur, &grp->bb_prealloc_list) {
|
|
|
|
pa = list_entry(cur, struct ext4_prealloc_space, pa_group_list);
|
|
|
|
spin_lock(&pa->pa_lock);
|
|
|
|
ext4_get_group_no_and_offset(sb, pa->pa_pstart,
|
|
|
|
&groupnr, &start);
|
|
|
|
len = pa->pa_len;
|
|
|
|
spin_unlock(&pa->pa_lock);
|
|
|
|
if (unlikely(len == 0))
|
|
|
|
continue;
|
|
|
|
BUG_ON(groupnr != group);
|
2022-02-16 07:02:47 +00:00
|
|
|
mb_set_bits(bitmap, start, len);
|
2008-01-29 05:19:52 +00:00
|
|
|
preallocated += len;
|
|
|
|
}
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "preallocated %d for group %u\n", preallocated, group);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
2020-08-17 07:36:15 +00:00
|
|
|
static void ext4_mb_mark_pa_deleted(struct super_block *sb,
|
|
|
|
struct ext4_prealloc_space *pa)
|
|
|
|
{
|
|
|
|
struct ext4_inode_info *ei;
|
|
|
|
|
|
|
|
if (pa->pa_deleted) {
|
|
|
|
ext4_warning(sb, "deleted pa, type:%d, pblk:%llu, lblk:%u, len:%d\n",
|
|
|
|
pa->pa_type, pa->pa_pstart, pa->pa_lstart,
|
|
|
|
pa->pa_len);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
pa->pa_deleted = 1;
|
|
|
|
|
|
|
|
if (pa->pa_type == MB_INODE_PA) {
|
|
|
|
ei = EXT4_I(pa->pa_inode);
|
|
|
|
atomic_dec(&ei->i_prealloc_active);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-03-25 08:13:35 +00:00
|
|
|
static inline void ext4_mb_pa_free(struct ext4_prealloc_space *pa)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
2023-03-25 08:13:35 +00:00
|
|
|
BUG_ON(!pa);
|
2013-12-03 23:10:28 +00:00
|
|
|
BUG_ON(atomic_read(&pa->pa_count));
|
|
|
|
BUG_ON(pa->pa_deleted == 0);
|
2008-01-29 05:19:52 +00:00
|
|
|
kmem_cache_free(ext4_pspace_cachep, pa);
|
|
|
|
}
|
|
|
|
|
2023-03-25 08:13:35 +00:00
|
|
|
static void ext4_mb_pa_callback(struct rcu_head *head)
|
|
|
|
{
|
|
|
|
struct ext4_prealloc_space *pa;
|
|
|
|
|
|
|
|
pa = container_of(head, struct ext4_prealloc_space, u.pa_rcu);
|
|
|
|
ext4_mb_pa_free(pa);
|
|
|
|
}
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
/*
|
|
|
|
* drops a reference to preallocated space descriptor
|
|
|
|
* if this was the last reference and the space is consumed
|
|
|
|
*/
|
|
|
|
static void ext4_mb_put_pa(struct ext4_allocation_context *ac,
|
|
|
|
struct super_block *sb, struct ext4_prealloc_space *pa)
|
|
|
|
{
|
2009-01-06 03:18:16 +00:00
|
|
|
ext4_group_t grp;
|
ext4: fix bb_prealloc_list corruption due to wrong group locking
This is for Red Hat bug 490026: EXT4 panic, list corruption in
ext4_mb_new_inode_pa
ext4_lock_group(sb, group) is supposed to protect this list for
each group, and a common code flow to remove an album is like
this:
ext4_get_group_no_and_offset(sb, pa->pa_pstart, &grp, NULL);
ext4_lock_group(sb, grp);
list_del(&pa->pa_group_list);
ext4_unlock_group(sb, grp);
so it's critical that we get the right group number back for
this prealloc context, to lock the right group (the one
associated with this pa) and prevent concurrent list manipulation.
however, ext4_mb_put_pa() passes in (pa->pa_pstart - 1) with a
comment, "-1 is to protect from crossing allocation group".
This makes sense for the group_pa, where pa_pstart is advanced
by the length which has been used (in ext4_mb_release_context()),
and when the entire length has been used, pa_pstart has been
advanced to the first block of the next group.
However, for inode_pa, pa_pstart is never advanced; it's just
set once to the first block in the group and not moved after
that. So in this case, if we subtract one in ext4_mb_put_pa(),
we are actually locking the *previous* group, and opening the
race with the other threads which do not subtract off the extra
block.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2009-03-17 03:25:40 +00:00
|
|
|
ext4_fsblk_t grp_blk;
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
struct ext4_inode_info *ei = EXT4_I(ac->ac_inode);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
/* in this short window concurrent discard can set pa_deleted */
|
|
|
|
spin_lock(&pa->pa_lock);
|
2013-12-03 23:10:28 +00:00
|
|
|
if (!atomic_dec_and_test(&pa->pa_count) || pa->pa_free != 0) {
|
|
|
|
spin_unlock(&pa->pa_lock);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
if (pa->pa_deleted == 1) {
|
|
|
|
spin_unlock(&pa->pa_lock);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-08-17 07:36:15 +00:00
|
|
|
ext4_mb_mark_pa_deleted(sb, pa);
|
2008-01-29 05:19:52 +00:00
|
|
|
spin_unlock(&pa->pa_lock);
|
|
|
|
|
ext4: fix bb_prealloc_list corruption due to wrong group locking
This is for Red Hat bug 490026: EXT4 panic, list corruption in
ext4_mb_new_inode_pa
ext4_lock_group(sb, group) is supposed to protect this list for
each group, and a common code flow to remove an album is like
this:
ext4_get_group_no_and_offset(sb, pa->pa_pstart, &grp, NULL);
ext4_lock_group(sb, grp);
list_del(&pa->pa_group_list);
ext4_unlock_group(sb, grp);
so it's critical that we get the right group number back for
this prealloc context, to lock the right group (the one
associated with this pa) and prevent concurrent list manipulation.
however, ext4_mb_put_pa() passes in (pa->pa_pstart - 1) with a
comment, "-1 is to protect from crossing allocation group".
This makes sense for the group_pa, where pa_pstart is advanced
by the length which has been used (in ext4_mb_release_context()),
and when the entire length has been used, pa_pstart has been
advanced to the first block of the next group.
However, for inode_pa, pa_pstart is never advanced; it's just
set once to the first block in the group and not moved after
that. So in this case, if we subtract one in ext4_mb_put_pa(),
we are actually locking the *previous* group, and opening the
race with the other threads which do not subtract off the extra
block.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2009-03-17 03:25:40 +00:00
|
|
|
grp_blk = pa->pa_pstart;
|
2010-05-17 11:00:00 +00:00
|
|
|
/*
|
2009-03-27 21:16:58 +00:00
|
|
|
* If doing group-based preallocation, pa_pstart may be in the
|
|
|
|
* next group when pa is used up
|
|
|
|
*/
|
|
|
|
if (pa->pa_type == MB_GROUP_PA)
|
ext4: fix bb_prealloc_list corruption due to wrong group locking
This is for Red Hat bug 490026: EXT4 panic, list corruption in
ext4_mb_new_inode_pa
ext4_lock_group(sb, group) is supposed to protect this list for
each group, and a common code flow to remove an album is like
this:
ext4_get_group_no_and_offset(sb, pa->pa_pstart, &grp, NULL);
ext4_lock_group(sb, grp);
list_del(&pa->pa_group_list);
ext4_unlock_group(sb, grp);
so it's critical that we get the right group number back for
this prealloc context, to lock the right group (the one
associated with this pa) and prevent concurrent list manipulation.
however, ext4_mb_put_pa() passes in (pa->pa_pstart - 1) with a
comment, "-1 is to protect from crossing allocation group".
This makes sense for the group_pa, where pa_pstart is advanced
by the length which has been used (in ext4_mb_release_context()),
and when the entire length has been used, pa_pstart has been
advanced to the first block of the next group.
However, for inode_pa, pa_pstart is never advanced; it's just
set once to the first block in the group and not moved after
that. So in this case, if we subtract one in ext4_mb_put_pa(),
we are actually locking the *previous* group, and opening the
race with the other threads which do not subtract off the extra
block.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2009-03-17 03:25:40 +00:00
|
|
|
grp_blk--;
|
|
|
|
|
2013-04-04 03:32:34 +00:00
|
|
|
grp = ext4_get_group_number(sb, grp_blk);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* possible race:
|
|
|
|
*
|
|
|
|
* P1 (buddy init) P2 (regular allocation)
|
|
|
|
* find block B in PA
|
|
|
|
* copy on-disk bitmap to buddy
|
|
|
|
* mark B in on-disk bitmap
|
|
|
|
* drop PA from group
|
|
|
|
* mark all PAs in buddy
|
|
|
|
*
|
|
|
|
* thus, P1 initializes buddy with B available. to prevent this
|
|
|
|
* we make "copy" and "mark all PAs" atomic and serialize "drop PA"
|
|
|
|
* against that pair
|
|
|
|
*/
|
|
|
|
ext4_lock_group(sb, grp);
|
|
|
|
list_del(&pa->pa_group_list);
|
|
|
|
ext4_unlock_group(sb, grp);
|
|
|
|
|
2023-03-25 08:13:40 +00:00
|
|
|
if (pa->pa_type == MB_INODE_PA) {
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
write_lock(pa->pa_node_lock.inode_lock);
|
|
|
|
rb_erase(&pa->pa_node.inode_node, &ei->i_prealloc_node);
|
|
|
|
write_unlock(pa->pa_node_lock.inode_lock);
|
|
|
|
ext4_mb_pa_free(pa);
|
2023-03-25 08:13:40 +00:00
|
|
|
} else {
|
|
|
|
spin_lock(pa->pa_node_lock.lg_lock);
|
|
|
|
list_del_rcu(&pa->pa_node.lg_list);
|
|
|
|
spin_unlock(pa->pa_node_lock.lg_lock);
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
call_rcu(&(pa)->u.pa_rcu, ext4_mb_pa_callback);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ext4_mb_pa_rb_insert(struct rb_root *root, struct rb_node *new)
|
|
|
|
{
|
|
|
|
struct rb_node **iter = &root->rb_node, *parent = NULL;
|
|
|
|
struct ext4_prealloc_space *iter_pa, *new_pa;
|
|
|
|
ext4_lblk_t iter_start, new_start;
|
|
|
|
|
|
|
|
while (*iter) {
|
|
|
|
iter_pa = rb_entry(*iter, struct ext4_prealloc_space,
|
|
|
|
pa_node.inode_node);
|
|
|
|
new_pa = rb_entry(new, struct ext4_prealloc_space,
|
|
|
|
pa_node.inode_node);
|
|
|
|
iter_start = iter_pa->pa_lstart;
|
|
|
|
new_start = new_pa->pa_lstart;
|
|
|
|
|
|
|
|
parent = *iter;
|
|
|
|
if (new_start < iter_start)
|
|
|
|
iter = &((*iter)->rb_left);
|
|
|
|
else
|
|
|
|
iter = &((*iter)->rb_right);
|
2023-03-25 08:13:40 +00:00
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
rb_link_node(new, parent, iter);
|
|
|
|
rb_insert_color(new, root);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* creates new preallocated space for given inode
|
|
|
|
*/
|
2020-05-20 06:40:32 +00:00
|
|
|
static noinline_for_stack void
|
2008-04-29 12:11:12 +00:00
|
|
|
ext4_mb_new_inode_pa(struct ext4_allocation_context *ac)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
|
|
|
struct super_block *sb = ac->ac_sb;
|
2011-09-09 22:48:51 +00:00
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_prealloc_space *pa;
|
|
|
|
struct ext4_group_info *grp;
|
|
|
|
struct ext4_inode_info *ei;
|
|
|
|
|
|
|
|
/* preallocate only when found space is larger then requested */
|
|
|
|
BUG_ON(ac->ac_o_ex.fe_len >= ac->ac_b_ex.fe_len);
|
|
|
|
BUG_ON(ac->ac_status != AC_STATUS_FOUND);
|
|
|
|
BUG_ON(!S_ISREG(ac->ac_inode->i_mode));
|
2020-05-20 06:40:32 +00:00
|
|
|
BUG_ON(ac->ac_pa == NULL);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2020-05-20 06:40:32 +00:00
|
|
|
pa = ac->ac_pa;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2023-05-30 12:33:49 +00:00
|
|
|
if (ac->ac_b_ex.fe_len < ac->ac_orig_goal_len) {
|
2023-07-24 12:10:58 +00:00
|
|
|
struct ext4_free_extent ex = {
|
|
|
|
.fe_logical = ac->ac_g_ex.fe_logical,
|
|
|
|
.fe_len = ac->ac_orig_goal_len,
|
|
|
|
};
|
|
|
|
loff_t orig_goal_end = extent_logical_end(sbi, &ex);
|
2024-02-01 14:18:45 +00:00
|
|
|
loff_t o_ex_end = extent_logical_end(sbi, &ac->ac_o_ex);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2024-02-01 14:18:45 +00:00
|
|
|
/*
|
|
|
|
* We can't allocate as much as normalizer wants, so we try
|
|
|
|
* to get proper lstart to cover the original request, except
|
|
|
|
* when the goal doesn't cover the original request as below:
|
|
|
|
*
|
|
|
|
* orig_ex:2045/2055(10), isize:8417280 -> normalized:0/2048
|
|
|
|
* best_ex:0/200(200) -> adjusted: 1848/2048(200)
|
|
|
|
*/
|
2008-01-29 05:19:52 +00:00
|
|
|
BUG_ON(ac->ac_g_ex.fe_logical > ac->ac_o_ex.fe_logical);
|
|
|
|
BUG_ON(ac->ac_g_ex.fe_len < ac->ac_o_ex.fe_len);
|
|
|
|
|
2023-03-25 08:13:39 +00:00
|
|
|
/*
|
|
|
|
* Use the below logic for adjusting best extent as it keeps
|
|
|
|
* fragmentation in check while ensuring logical range of best
|
|
|
|
* extent doesn't overflow out of goal extent:
|
|
|
|
*
|
2023-05-30 12:33:49 +00:00
|
|
|
* 1. Check if best ex can be kept at end of goal (before
|
|
|
|
* cr_best_avail trimmed it) and still cover original start
|
2023-03-25 08:13:39 +00:00
|
|
|
* 2. Else, check if best ex can be kept at start of goal and
|
2024-02-01 14:18:45 +00:00
|
|
|
* still cover original end
|
2023-03-25 08:13:39 +00:00
|
|
|
* 3. Else, keep the best ex at start of original request.
|
|
|
|
*/
|
2023-07-24 12:10:58 +00:00
|
|
|
ex.fe_len = ac->ac_b_ex.fe_len;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2023-07-24 12:10:58 +00:00
|
|
|
ex.fe_logical = orig_goal_end - EXT4_C2B(sbi, ex.fe_len);
|
|
|
|
if (ac->ac_o_ex.fe_logical >= ex.fe_logical)
|
2023-03-25 08:13:39 +00:00
|
|
|
goto adjust_bex;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2023-07-24 12:10:58 +00:00
|
|
|
ex.fe_logical = ac->ac_g_ex.fe_logical;
|
2024-02-01 14:18:45 +00:00
|
|
|
if (o_ex_end <= extent_logical_end(sbi, &ex))
|
2023-07-24 12:10:58 +00:00
|
|
|
goto adjust_bex;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2023-07-24 12:10:58 +00:00
|
|
|
ex.fe_logical = ac->ac_o_ex.fe_logical;
|
2023-03-25 08:13:39 +00:00
|
|
|
adjust_bex:
|
2023-07-24 12:10:58 +00:00
|
|
|
ac->ac_b_ex.fe_logical = ex.fe_logical;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
BUG_ON(ac->ac_o_ex.fe_logical < ac->ac_b_ex.fe_logical);
|
2023-07-24 12:10:58 +00:00
|
|
|
BUG_ON(extent_logical_end(sbi, &ex) > orig_goal_end);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
pa->pa_lstart = ac->ac_b_ex.fe_logical;
|
|
|
|
pa->pa_pstart = ext4_grp_offs_to_block(sb, &ac->ac_b_ex);
|
|
|
|
pa->pa_len = ac->ac_b_ex.fe_len;
|
|
|
|
pa->pa_free = pa->pa_len;
|
|
|
|
spin_lock_init(&pa->pa_lock);
|
2009-02-14 15:31:16 +00:00
|
|
|
INIT_LIST_HEAD(&pa->pa_group_list);
|
2008-01-29 05:19:52 +00:00
|
|
|
pa->pa_deleted = 0;
|
2009-03-27 21:16:58 +00:00
|
|
|
pa->pa_type = MB_INODE_PA;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "new inode pa %p: %llu/%d for %u\n", pa, pa->pa_pstart,
|
|
|
|
pa->pa_len, pa->pa_lstart);
|
2009-06-17 15:48:11 +00:00
|
|
|
trace_ext4_mb_new_inode_pa(ac, pa);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2011-09-09 22:48:51 +00:00
|
|
|
atomic_add(pa->pa_free, &sbi->s_mb_preallocated);
|
2023-03-03 17:21:04 +00:00
|
|
|
ext4_mb_use_inode_pa(ac, pa);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
ei = EXT4_I(ac->ac_inode);
|
|
|
|
grp = ext4_get_group_info(sb, ac->ac_b_ex.fe_group);
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
if (!grp)
|
|
|
|
return;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2023-03-25 08:13:40 +00:00
|
|
|
pa->pa_node_lock.inode_lock = &ei->i_prealloc_lock;
|
2008-01-29 05:19:52 +00:00
|
|
|
pa->pa_inode = ac->ac_inode;
|
|
|
|
|
|
|
|
list_add(&pa->pa_group_list, &grp->bb_prealloc_list);
|
|
|
|
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
write_lock(pa->pa_node_lock.inode_lock);
|
|
|
|
ext4_mb_pa_rb_insert(&ei->i_prealloc_node, &pa->pa_node.inode_node);
|
|
|
|
write_unlock(pa->pa_node_lock.inode_lock);
|
2020-08-17 07:36:15 +00:00
|
|
|
atomic_inc(&ei->i_prealloc_active);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* creates new preallocated space for locality group inodes belongs to
|
|
|
|
*/
|
2020-05-20 06:40:32 +00:00
|
|
|
static noinline_for_stack void
|
2008-04-29 12:11:12 +00:00
|
|
|
ext4_mb_new_group_pa(struct ext4_allocation_context *ac)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
|
|
|
struct super_block *sb = ac->ac_sb;
|
|
|
|
struct ext4_locality_group *lg;
|
|
|
|
struct ext4_prealloc_space *pa;
|
|
|
|
struct ext4_group_info *grp;
|
|
|
|
|
|
|
|
/* preallocate only when found space is larger then requested */
|
|
|
|
BUG_ON(ac->ac_o_ex.fe_len >= ac->ac_b_ex.fe_len);
|
|
|
|
BUG_ON(ac->ac_status != AC_STATUS_FOUND);
|
|
|
|
BUG_ON(!S_ISREG(ac->ac_inode->i_mode));
|
2020-05-20 06:40:32 +00:00
|
|
|
BUG_ON(ac->ac_pa == NULL);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2020-05-20 06:40:32 +00:00
|
|
|
pa = ac->ac_pa;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
pa->pa_pstart = ext4_grp_offs_to_block(sb, &ac->ac_b_ex);
|
|
|
|
pa->pa_lstart = pa->pa_pstart;
|
|
|
|
pa->pa_len = ac->ac_b_ex.fe_len;
|
|
|
|
pa->pa_free = pa->pa_len;
|
|
|
|
spin_lock_init(&pa->pa_lock);
|
2023-03-25 08:13:40 +00:00
|
|
|
INIT_LIST_HEAD(&pa->pa_node.lg_list);
|
2009-02-14 15:31:16 +00:00
|
|
|
INIT_LIST_HEAD(&pa->pa_group_list);
|
2008-01-29 05:19:52 +00:00
|
|
|
pa->pa_deleted = 0;
|
2009-03-27 21:16:58 +00:00
|
|
|
pa->pa_type = MB_GROUP_PA;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "new group pa %p: %llu/%d for %u\n", pa, pa->pa_pstart,
|
|
|
|
pa->pa_len, pa->pa_lstart);
|
2009-06-17 15:48:11 +00:00
|
|
|
trace_ext4_mb_new_group_pa(ac, pa);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
ext4_mb_use_group_pa(ac, pa);
|
|
|
|
atomic_add(pa->pa_free, &EXT4_SB(sb)->s_mb_preallocated);
|
|
|
|
|
|
|
|
grp = ext4_get_group_info(sb, ac->ac_b_ex.fe_group);
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
if (!grp)
|
|
|
|
return;
|
2008-01-29 05:19:52 +00:00
|
|
|
lg = ac->ac_lg;
|
|
|
|
BUG_ON(lg == NULL);
|
|
|
|
|
2023-03-25 08:13:40 +00:00
|
|
|
pa->pa_node_lock.lg_lock = &lg->lg_prealloc_lock;
|
2008-01-29 05:19:52 +00:00
|
|
|
pa->pa_inode = NULL;
|
|
|
|
|
|
|
|
list_add(&pa->pa_group_list, &grp->bb_prealloc_list);
|
|
|
|
|
2008-07-23 18:14:05 +00:00
|
|
|
/*
|
|
|
|
* We will later add the new pa to the right bucket
|
|
|
|
* after updating the pa_free in ext4_mb_release_context
|
|
|
|
*/
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
2020-05-20 06:40:32 +00:00
|
|
|
static void ext4_mb_new_preallocation(struct ext4_allocation_context *ac)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
|
|
|
if (ac->ac_flags & EXT4_MB_HINT_GROUP_ALLOC)
|
2020-05-20 06:40:32 +00:00
|
|
|
ext4_mb_new_group_pa(ac);
|
2008-01-29 05:19:52 +00:00
|
|
|
else
|
2020-05-20 06:40:32 +00:00
|
|
|
ext4_mb_new_inode_pa(ac);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* finds all unused blocks in on-disk bitmap, frees them in
|
|
|
|
* in-core bitmap and buddy.
|
|
|
|
* @pa must be unlinked from inode and group lists, so that
|
|
|
|
* nobody else can find/use it.
|
|
|
|
* the caller MUST hold group/inode locks.
|
|
|
|
* TODO: optimize the case when there are no in-core structures yet
|
|
|
|
*/
|
2024-01-05 09:20:59 +00:00
|
|
|
static noinline_for_stack void
|
2008-04-29 12:11:12 +00:00
|
|
|
ext4_mb_release_inode_pa(struct ext4_buddy *e4b, struct buffer_head *bitmap_bh,
|
2010-10-28 01:30:07 +00:00
|
|
|
struct ext4_prealloc_space *pa)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
|
|
|
struct super_block *sb = e4b->bd_sb;
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
2008-11-05 05:14:04 +00:00
|
|
|
unsigned int end;
|
|
|
|
unsigned int next;
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_group_t group;
|
|
|
|
ext4_grpblk_t bit;
|
2009-01-04 01:03:21 +00:00
|
|
|
unsigned long long grp_blk_start;
|
2008-01-29 05:19:52 +00:00
|
|
|
int free = 0;
|
|
|
|
|
|
|
|
BUG_ON(pa->pa_deleted == 0);
|
|
|
|
ext4_get_group_no_and_offset(sb, pa->pa_pstart, &group, &bit);
|
2011-09-09 22:48:51 +00:00
|
|
|
grp_blk_start = pa->pa_pstart - EXT4_C2B(sbi, bit);
|
2008-01-29 05:19:52 +00:00
|
|
|
BUG_ON(group != e4b->bd_group && pa->pa_len != 0);
|
|
|
|
end = bit + pa->pa_len;
|
|
|
|
|
|
|
|
while (bit < end) {
|
2008-02-23 06:38:34 +00:00
|
|
|
bit = mb_find_next_zero_bit(bitmap_bh->b_data, end, bit);
|
2008-01-29 05:19:52 +00:00
|
|
|
if (bit >= end)
|
|
|
|
break;
|
2008-02-23 06:38:34 +00:00
|
|
|
next = mb_find_next_bit(bitmap_bh->b_data, end, bit);
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "free preallocated %u/%u in group %u\n",
|
2010-06-14 17:28:03 +00:00
|
|
|
(unsigned) ext4_group_first_block_no(sb, group) + bit,
|
|
|
|
(unsigned) next - bit, (unsigned) group);
|
2008-01-29 05:19:52 +00:00
|
|
|
free += next - bit;
|
|
|
|
|
2010-10-28 01:30:07 +00:00
|
|
|
trace_ext4_mballoc_discard(sb, NULL, group, bit, next - bit);
|
2011-09-09 22:48:51 +00:00
|
|
|
trace_ext4_mb_release_inode_pa(pa, (grp_blk_start +
|
|
|
|
EXT4_C2B(sbi, bit)),
|
2011-06-06 13:51:52 +00:00
|
|
|
next - bit);
|
2008-01-29 05:19:52 +00:00
|
|
|
mb_free_blocks(pa->pa_inode, e4b, bit, next - bit);
|
|
|
|
bit = next + 1;
|
|
|
|
}
|
|
|
|
if (free != pa->pa_free) {
|
2011-08-01 21:41:35 +00:00
|
|
|
ext4_msg(e4b->bd_sb, KERN_CRIT,
|
2020-05-10 06:24:44 +00:00
|
|
|
"pa %p: logic %lu, phys. %lu, len %d",
|
2011-08-01 21:41:35 +00:00
|
|
|
pa, (unsigned long) pa->pa_lstart,
|
|
|
|
(unsigned long) pa->pa_pstart,
|
2020-05-10 06:24:44 +00:00
|
|
|
pa->pa_len);
|
2010-06-29 16:54:28 +00:00
|
|
|
ext4_grp_locked_error(sb, group, 0, 0, "free %u, pa_free %u",
|
2009-01-06 03:19:52 +00:00
|
|
|
free, pa->pa_free);
|
2008-02-15 18:48:21 +00:00
|
|
|
/*
|
|
|
|
* pa is already deleted so we use the value obtained
|
|
|
|
* from the bitmap and continue.
|
|
|
|
*/
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
atomic_add(free, &sbi->s_mb_discarded);
|
|
|
|
}
|
|
|
|
|
2024-01-05 09:21:00 +00:00
|
|
|
static noinline_for_stack void
|
2008-04-29 12:11:12 +00:00
|
|
|
ext4_mb_release_group_pa(struct ext4_buddy *e4b,
|
2010-10-28 01:30:07 +00:00
|
|
|
struct ext4_prealloc_space *pa)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
|
|
|
struct super_block *sb = e4b->bd_sb;
|
|
|
|
ext4_group_t group;
|
|
|
|
ext4_grpblk_t bit;
|
|
|
|
|
2011-12-18 20:49:54 +00:00
|
|
|
trace_ext4_mb_release_group_pa(sb, pa);
|
2008-01-29 05:19:52 +00:00
|
|
|
BUG_ON(pa->pa_deleted == 0);
|
|
|
|
ext4_get_group_no_and_offset(sb, pa->pa_pstart, &group, &bit);
|
2023-04-29 20:14:46 +00:00
|
|
|
if (unlikely(group != e4b->bd_group && pa->pa_len != 0)) {
|
|
|
|
ext4_warning(sb, "bad group: expected %u, group %u, pa_start %llu",
|
|
|
|
e4b->bd_group, group, pa->pa_pstart);
|
2024-01-05 09:21:00 +00:00
|
|
|
return;
|
2023-04-29 20:14:46 +00:00
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
mb_free_blocks(pa->pa_inode, e4b, bit, pa->pa_len);
|
|
|
|
atomic_add(pa->pa_len, &EXT4_SB(sb)->s_mb_discarded);
|
2010-10-28 01:30:07 +00:00
|
|
|
trace_ext4_mballoc_discard(sb, NULL, group, bit, pa->pa_len);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* releases all preallocations in given group
|
|
|
|
*
|
|
|
|
* first, we need to decide discard policy:
|
|
|
|
* - when do we discard
|
|
|
|
* 1) ENOSPC
|
|
|
|
* - how many do we discard
|
|
|
|
* 1) how many requested
|
|
|
|
*/
|
2008-04-29 12:11:12 +00:00
|
|
|
static noinline_for_stack int
|
|
|
|
ext4_mb_discard_group_preallocations(struct super_block *sb,
|
ext4: fix a possible ABBA deadlock due to busy PA
We found on older kernel (3.10) that in the scenario of insufficient
disk space, system may trigger an ABBA deadlock problem, it seems that
this problem still exists in latest kernel, try to fix it here. The
main process triggered by this problem is that task A occupies the PA
and waits for the jbd2 transaction finish, the jbd2 transaction waits
for the completion of task B's IO (plug_list), but task B waits for
the release of PA by task A to finish discard, which indirectly forms
an ABBA deadlock. The related calltrace is as follows:
Task A
vfs_write
ext4_mb_new_blocks()
ext4_mb_mark_diskspace_used() JBD2
jbd2_journal_get_write_access() -> jbd2_journal_commit_transaction()
->schedule() filemap_fdatawait()
| |
| Task B |
| do_unlinkat() |
| ext4_evict_inode() |
| jbd2_journal_begin_ordered_truncate() |
| filemap_fdatawrite_range() |
| ext4_mb_new_blocks() |
-ext4_mb_discard_group_preallocations() <-----
Here, try to cancel ext4_mb_discard_group_preallocations() internal
retry due to PA busy, and do a limited number of retries inside
ext4_mb_discard_preallocations(), which can circumvent the above
problems, but also has some advantages:
1. Since the PA is in a busy state, if other groups have free PAs,
keeping the current PA may help to reduce fragmentation.
2. Continue to traverse forward instead of waiting for the current
group PA to be released. In most scenarios, the PA discard time
can be reduced.
However, in the case of smaller free space, if only a few groups have
space, then due to multiple traversals of the group, it may increase
CPU overhead. But in contrast, I feel that the overall benefit is
better than the cost.
Signed-off-by: Chunguang Xu <brookxu@tencent.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/1637630277-23496-1-git-send-email-brookxu.cn@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
2021-11-23 01:17:57 +00:00
|
|
|
ext4_group_t group, int *busy)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
|
|
|
struct ext4_group_info *grp = ext4_get_group_info(sb, group);
|
|
|
|
struct buffer_head *bitmap_bh = NULL;
|
|
|
|
struct ext4_prealloc_space *pa, *tmp;
|
2023-08-12 07:18:39 +00:00
|
|
|
LIST_HEAD(list);
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_buddy e4b;
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
struct ext4_inode_info *ei;
|
2008-01-29 05:19:52 +00:00
|
|
|
int err;
|
ext4: fix a possible ABBA deadlock due to busy PA
We found on older kernel (3.10) that in the scenario of insufficient
disk space, system may trigger an ABBA deadlock problem, it seems that
this problem still exists in latest kernel, try to fix it here. The
main process triggered by this problem is that task A occupies the PA
and waits for the jbd2 transaction finish, the jbd2 transaction waits
for the completion of task B's IO (plug_list), but task B waits for
the release of PA by task A to finish discard, which indirectly forms
an ABBA deadlock. The related calltrace is as follows:
Task A
vfs_write
ext4_mb_new_blocks()
ext4_mb_mark_diskspace_used() JBD2
jbd2_journal_get_write_access() -> jbd2_journal_commit_transaction()
->schedule() filemap_fdatawait()
| |
| Task B |
| do_unlinkat() |
| ext4_evict_inode() |
| jbd2_journal_begin_ordered_truncate() |
| filemap_fdatawrite_range() |
| ext4_mb_new_blocks() |
-ext4_mb_discard_group_preallocations() <-----
Here, try to cancel ext4_mb_discard_group_preallocations() internal
retry due to PA busy, and do a limited number of retries inside
ext4_mb_discard_preallocations(), which can circumvent the above
problems, but also has some advantages:
1. Since the PA is in a busy state, if other groups have free PAs,
keeping the current PA may help to reduce fragmentation.
2. Continue to traverse forward instead of waiting for the current
group PA to be released. In most scenarios, the PA discard time
can be reduced.
However, in the case of smaller free space, if only a few groups have
space, then due to multiple traversals of the group, it may increase
CPU overhead. But in contrast, I feel that the overall benefit is
better than the cost.
Signed-off-by: Chunguang Xu <brookxu@tencent.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/1637630277-23496-1-git-send-email-brookxu.cn@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
2021-11-23 01:17:57 +00:00
|
|
|
int free = 0;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
if (!grp)
|
|
|
|
return 0;
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "discard preallocation for group %u\n", group);
|
2008-01-29 05:19:52 +00:00
|
|
|
if (list_empty(&grp->bb_prealloc_list))
|
2020-05-10 06:24:43 +00:00
|
|
|
goto out_dbg;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2008-07-11 23:27:31 +00:00
|
|
|
bitmap_bh = ext4_read_block_bitmap(sb, group);
|
2015-10-18 01:33:24 +00:00
|
|
|
if (IS_ERR(bitmap_bh)) {
|
|
|
|
err = PTR_ERR(bitmap_bh);
|
2020-03-28 23:33:43 +00:00
|
|
|
ext4_error_err(sb, -err,
|
|
|
|
"Error %d reading block bitmap for %u",
|
|
|
|
err, group);
|
2020-05-10 06:24:43 +00:00
|
|
|
goto out_dbg;
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
err = ext4_mb_load_buddy(sb, group, &e4b);
|
2008-07-23 18:09:29 +00:00
|
|
|
if (err) {
|
2017-05-22 02:35:23 +00:00
|
|
|
ext4_warning(sb, "Error %d loading buddy information for %u",
|
|
|
|
err, group);
|
2008-07-23 18:09:29 +00:00
|
|
|
put_bh(bitmap_bh);
|
2020-05-10 06:24:43 +00:00
|
|
|
goto out_dbg;
|
2008-07-23 18:09:29 +00:00
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
ext4_lock_group(sb, group);
|
|
|
|
list_for_each_entry_safe(pa, tmp,
|
|
|
|
&grp->bb_prealloc_list, pa_group_list) {
|
|
|
|
spin_lock(&pa->pa_lock);
|
|
|
|
if (atomic_read(&pa->pa_count)) {
|
|
|
|
spin_unlock(&pa->pa_lock);
|
ext4: fix a possible ABBA deadlock due to busy PA
We found on older kernel (3.10) that in the scenario of insufficient
disk space, system may trigger an ABBA deadlock problem, it seems that
this problem still exists in latest kernel, try to fix it here. The
main process triggered by this problem is that task A occupies the PA
and waits for the jbd2 transaction finish, the jbd2 transaction waits
for the completion of task B's IO (plug_list), but task B waits for
the release of PA by task A to finish discard, which indirectly forms
an ABBA deadlock. The related calltrace is as follows:
Task A
vfs_write
ext4_mb_new_blocks()
ext4_mb_mark_diskspace_used() JBD2
jbd2_journal_get_write_access() -> jbd2_journal_commit_transaction()
->schedule() filemap_fdatawait()
| |
| Task B |
| do_unlinkat() |
| ext4_evict_inode() |
| jbd2_journal_begin_ordered_truncate() |
| filemap_fdatawrite_range() |
| ext4_mb_new_blocks() |
-ext4_mb_discard_group_preallocations() <-----
Here, try to cancel ext4_mb_discard_group_preallocations() internal
retry due to PA busy, and do a limited number of retries inside
ext4_mb_discard_preallocations(), which can circumvent the above
problems, but also has some advantages:
1. Since the PA is in a busy state, if other groups have free PAs,
keeping the current PA may help to reduce fragmentation.
2. Continue to traverse forward instead of waiting for the current
group PA to be released. In most scenarios, the PA discard time
can be reduced.
However, in the case of smaller free space, if only a few groups have
space, then due to multiple traversals of the group, it may increase
CPU overhead. But in contrast, I feel that the overall benefit is
better than the cost.
Signed-off-by: Chunguang Xu <brookxu@tencent.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/1637630277-23496-1-git-send-email-brookxu.cn@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
2021-11-23 01:17:57 +00:00
|
|
|
*busy = 1;
|
2008-01-29 05:19:52 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (pa->pa_deleted) {
|
|
|
|
spin_unlock(&pa->pa_lock);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* seems this one can be freed ... */
|
2020-08-17 07:36:15 +00:00
|
|
|
ext4_mb_mark_pa_deleted(sb, pa);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2020-09-16 11:38:59 +00:00
|
|
|
if (!free)
|
|
|
|
this_cpu_inc(discard_pa_seq);
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
/* we can trust pa_free ... */
|
|
|
|
free += pa->pa_free;
|
|
|
|
|
|
|
|
spin_unlock(&pa->pa_lock);
|
|
|
|
|
|
|
|
list_del(&pa->pa_group_list);
|
|
|
|
list_add(&pa->u.pa_tmp_list, &list);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* now free all selected PAs */
|
|
|
|
list_for_each_entry_safe(pa, tmp, &list, u.pa_tmp_list) {
|
|
|
|
|
|
|
|
/* remove from object (inode or locality group) */
|
2023-03-25 08:13:40 +00:00
|
|
|
if (pa->pa_type == MB_GROUP_PA) {
|
|
|
|
spin_lock(pa->pa_node_lock.lg_lock);
|
|
|
|
list_del_rcu(&pa->pa_node.lg_list);
|
|
|
|
spin_unlock(pa->pa_node_lock.lg_lock);
|
|
|
|
} else {
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
write_lock(pa->pa_node_lock.inode_lock);
|
|
|
|
ei = EXT4_I(pa->pa_inode);
|
|
|
|
rb_erase(&pa->pa_node.inode_node, &ei->i_prealloc_node);
|
|
|
|
write_unlock(pa->pa_node_lock.inode_lock);
|
2023-03-25 08:13:40 +00:00
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
list_del(&pa->u.pa_tmp_list);
|
|
|
|
|
|
|
|
if (pa->pa_type == MB_GROUP_PA) {
|
2010-10-28 01:30:07 +00:00
|
|
|
ext4_mb_release_group_pa(&e4b, pa);
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
call_rcu(&(pa)->u.pa_rcu, ext4_mb_pa_callback);
|
|
|
|
} else {
|
2010-10-28 01:30:07 +00:00
|
|
|
ext4_mb_release_inode_pa(&e4b, bitmap_bh, pa);
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
ext4_mb_pa_free(pa);
|
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
ext4_unlock_group(sb, group);
|
2010-05-14 04:00:00 +00:00
|
|
|
ext4_mb_unload_buddy(&e4b);
|
2008-01-29 05:19:52 +00:00
|
|
|
put_bh(bitmap_bh);
|
2020-05-10 06:24:43 +00:00
|
|
|
out_dbg:
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "discarded (%d) blocks preallocated for group %u bb_free (%d)\n",
|
ext4: fix a possible ABBA deadlock due to busy PA
We found on older kernel (3.10) that in the scenario of insufficient
disk space, system may trigger an ABBA deadlock problem, it seems that
this problem still exists in latest kernel, try to fix it here. The
main process triggered by this problem is that task A occupies the PA
and waits for the jbd2 transaction finish, the jbd2 transaction waits
for the completion of task B's IO (plug_list), but task B waits for
the release of PA by task A to finish discard, which indirectly forms
an ABBA deadlock. The related calltrace is as follows:
Task A
vfs_write
ext4_mb_new_blocks()
ext4_mb_mark_diskspace_used() JBD2
jbd2_journal_get_write_access() -> jbd2_journal_commit_transaction()
->schedule() filemap_fdatawait()
| |
| Task B |
| do_unlinkat() |
| ext4_evict_inode() |
| jbd2_journal_begin_ordered_truncate() |
| filemap_fdatawrite_range() |
| ext4_mb_new_blocks() |
-ext4_mb_discard_group_preallocations() <-----
Here, try to cancel ext4_mb_discard_group_preallocations() internal
retry due to PA busy, and do a limited number of retries inside
ext4_mb_discard_preallocations(), which can circumvent the above
problems, but also has some advantages:
1. Since the PA is in a busy state, if other groups have free PAs,
keeping the current PA may help to reduce fragmentation.
2. Continue to traverse forward instead of waiting for the current
group PA to be released. In most scenarios, the PA discard time
can be reduced.
However, in the case of smaller free space, if only a few groups have
space, then due to multiple traversals of the group, it may increase
CPU overhead. But in contrast, I feel that the overall benefit is
better than the cost.
Signed-off-by: Chunguang Xu <brookxu@tencent.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/1637630277-23496-1-git-send-email-brookxu.cn@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
2021-11-23 01:17:57 +00:00
|
|
|
free, group, grp->bb_free);
|
|
|
|
return free;
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* releases all non-used preallocated blocks for given inode
|
|
|
|
*
|
|
|
|
* It's important to discard preallocations under i_data_sem
|
|
|
|
* We don't want another block to be served from the prealloc
|
|
|
|
* space when we are discarding the inode prealloc space.
|
|
|
|
*
|
|
|
|
* FIXME!! Make sure it is valid at all the call sites
|
|
|
|
*/
|
2024-01-05 09:21:01 +00:00
|
|
|
void ext4_discard_preallocations(struct inode *inode)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
|
|
|
struct ext4_inode_info *ei = EXT4_I(inode);
|
|
|
|
struct super_block *sb = inode->i_sb;
|
|
|
|
struct buffer_head *bitmap_bh = NULL;
|
|
|
|
struct ext4_prealloc_space *pa, *tmp;
|
|
|
|
ext4_group_t group = 0;
|
2023-08-12 07:18:39 +00:00
|
|
|
LIST_HEAD(list);
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_buddy e4b;
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
struct rb_node *iter;
|
2008-01-29 05:19:52 +00:00
|
|
|
int err;
|
|
|
|
|
2024-01-05 09:21:02 +00:00
|
|
|
if (!S_ISREG(inode->i_mode))
|
2008-01-29 05:19:52 +00:00
|
|
|
return;
|
|
|
|
|
2020-10-15 20:37:59 +00:00
|
|
|
if (EXT4_SB(sb)->s_mount_state & EXT4_FC_REPLAY)
|
|
|
|
return;
|
|
|
|
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "discard preallocation for inode %lu\n",
|
|
|
|
inode->i_ino);
|
2020-08-17 07:36:15 +00:00
|
|
|
trace_ext4_discard_preallocations(inode,
|
2024-01-05 09:21:02 +00:00
|
|
|
atomic_read(&ei->i_prealloc_active));
|
2020-08-17 07:36:15 +00:00
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
repeat:
|
|
|
|
/* first, collect all pa's in the inode */
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
write_lock(&ei->i_prealloc_lock);
|
2024-01-05 09:21:01 +00:00
|
|
|
for (iter = rb_first(&ei->i_prealloc_node); iter;
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
iter = rb_next(iter)) {
|
|
|
|
pa = rb_entry(iter, struct ext4_prealloc_space,
|
|
|
|
pa_node.inode_node);
|
2023-03-25 08:13:40 +00:00
|
|
|
BUG_ON(pa->pa_node_lock.inode_lock != &ei->i_prealloc_lock);
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
spin_lock(&pa->pa_lock);
|
|
|
|
if (atomic_read(&pa->pa_count)) {
|
|
|
|
/* this shouldn't happen often - nobody should
|
|
|
|
* use preallocation while we're discarding it */
|
|
|
|
spin_unlock(&pa->pa_lock);
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
write_unlock(&ei->i_prealloc_lock);
|
2011-08-01 21:41:35 +00:00
|
|
|
ext4_msg(sb, KERN_ERR,
|
|
|
|
"uh-oh! used pa while discarding");
|
2008-01-29 05:19:52 +00:00
|
|
|
WARN_ON(1);
|
|
|
|
schedule_timeout_uninterruptible(HZ);
|
|
|
|
goto repeat;
|
|
|
|
|
|
|
|
}
|
|
|
|
if (pa->pa_deleted == 0) {
|
2020-08-17 07:36:15 +00:00
|
|
|
ext4_mb_mark_pa_deleted(sb, pa);
|
2008-01-29 05:19:52 +00:00
|
|
|
spin_unlock(&pa->pa_lock);
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
rb_erase(&pa->pa_node.inode_node, &ei->i_prealloc_node);
|
2008-01-29 05:19:52 +00:00
|
|
|
list_add(&pa->u.pa_tmp_list, &list);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* someone is deleting pa right now */
|
|
|
|
spin_unlock(&pa->pa_lock);
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
write_unlock(&ei->i_prealloc_lock);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
/* we have to wait here because pa_deleted
|
|
|
|
* doesn't mean pa is already unlinked from
|
|
|
|
* the list. as we might be called from
|
|
|
|
* ->clear_inode() the inode will get freed
|
|
|
|
* and concurrent thread which is unlinking
|
|
|
|
* pa from inode's list may access already
|
|
|
|
* freed memory, bad-bad-bad */
|
|
|
|
|
|
|
|
/* XXX: if this happens too often, we can
|
|
|
|
* add a flag to force wait only in case
|
|
|
|
* of ->clear_inode(), but not in case of
|
|
|
|
* regular truncate */
|
|
|
|
schedule_timeout_uninterruptible(HZ);
|
|
|
|
goto repeat;
|
|
|
|
}
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
write_unlock(&ei->i_prealloc_lock);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
list_for_each_entry_safe(pa, tmp, &list, u.pa_tmp_list) {
|
2009-03-27 21:16:58 +00:00
|
|
|
BUG_ON(pa->pa_type != MB_INODE_PA);
|
2013-04-04 03:32:34 +00:00
|
|
|
group = ext4_get_group_number(sb, pa->pa_pstart);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2017-05-22 02:35:23 +00:00
|
|
|
err = ext4_mb_load_buddy_gfp(sb, group, &e4b,
|
|
|
|
GFP_NOFS|__GFP_NOFAIL);
|
2008-07-23 18:09:29 +00:00
|
|
|
if (err) {
|
2020-03-28 23:33:43 +00:00
|
|
|
ext4_error_err(sb, -err, "Error %d loading buddy information for %u",
|
|
|
|
err, group);
|
2008-07-23 18:09:29 +00:00
|
|
|
continue;
|
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2008-07-11 23:27:31 +00:00
|
|
|
bitmap_bh = ext4_read_block_bitmap(sb, group);
|
2015-10-18 01:33:24 +00:00
|
|
|
if (IS_ERR(bitmap_bh)) {
|
|
|
|
err = PTR_ERR(bitmap_bh);
|
2020-03-28 23:33:43 +00:00
|
|
|
ext4_error_err(sb, -err, "Error %d reading block bitmap for %u",
|
|
|
|
err, group);
|
2010-05-14 04:00:00 +00:00
|
|
|
ext4_mb_unload_buddy(&e4b);
|
2008-07-23 18:09:29 +00:00
|
|
|
continue;
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
ext4_lock_group(sb, group);
|
|
|
|
list_del(&pa->pa_group_list);
|
2010-10-28 01:30:07 +00:00
|
|
|
ext4_mb_release_inode_pa(&e4b, bitmap_bh, pa);
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_unlock_group(sb, group);
|
|
|
|
|
2010-05-14 04:00:00 +00:00
|
|
|
ext4_mb_unload_buddy(&e4b);
|
2008-01-29 05:19:52 +00:00
|
|
|
put_bh(bitmap_bh);
|
|
|
|
|
|
|
|
list_del(&pa->u.pa_tmp_list);
|
ext4: Use rbtrees to manage PAs instead of inode i_prealloc_list
Currently, the kernel uses i_prealloc_list to hold all the inode
preallocations. This is known to cause degradation in performance in
workloads which perform large number of sparse writes on a single file.
This is mainly because functions like ext4_mb_normalize_request() and
ext4_mb_use_preallocated() iterate over this complete list, resulting in
slowdowns when large number of PAs are present.
Patch 27bc446e2 partially fixed this by enforcing a limit of 512 for
the inode preallocation list and adding logic to continually trim the
list if it grows above the threshold, however our testing revealed that
a hardcoded value is not suitable for all kinds of workloads.
To optimize this, add an rbtree to the inode and hold the inode
preallocations in this rbtree. This will make iterating over inode PAs
faster and scale much better than a linked list. Additionally, we also
had to remove the LRU logic that was added during trimming of the list
(in ext4_mb_release_context()) as it will add extra overhead in rbtree.
The discards now happen in the lowest-logical-offset-first order.
** Locking notes **
With the introduction of rbtree to maintain inode PAs, we can't use RCU
to walk the tree for searching since it can result in partial traversals
which might miss some nodes(or entire subtrees) while discards happen
in parallel (which happens under a lock). Hence this patch converts the
ei->i_prealloc_lock spin_lock to rw_lock.
Almost all the codepaths that read/modify the PA rbtrees are protected
by the higher level inode->i_data_sem (except
ext4_mb_discard_group_preallocations() and ext4_clear_inode()) IIUC, the
only place we need lock protection is when one thread is reading
"searching" the PA rbtree (earlier protected under rcu_read_lock()) and
another is "deleting" the PAs in ext4_mb_discard_group_preallocations()
function (which iterates all the PAs using the grp->bb_prealloc_list and
deletes PAs from the tree without taking any inode lock (i_data_sem)).
So, this patch converts all rcu_read_lock/unlock() paths for inode list
PA to use read_lock() and all places where we were using
ei->i_prealloc_lock spinlock will now be using write_lock().
Note that this makes the fast path (searching of the right PA e.g.
ext4_mb_use_preallocated() or ext4_mb_normalize_request()), now use
read_lock() instead of rcu_read_lock/unlock(). Ths also will now block
due to slow discard path (ext4_mb_discard_group_preallocations()) which
uses write_lock().
But this is not as bad as it looks. This is because -
1. The slow path only occurs when the normal allocation failed and we
can say that we are low on disk space. One can argue this scenario
won't be much frequent.
2. ext4_mb_discard_group_preallocations(), locks and unlocks the rwlock
for deleting every individual PA. This gives enough opportunity for
the fast path to acquire the read_lock for searching the PA inode
list.
Suggested-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/4137bce8f6948fedd8bae134dabae24acfe699c6.1679731817.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-03-25 08:13:41 +00:00
|
|
|
ext4_mb_pa_free(pa);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-05-20 06:40:32 +00:00
|
|
|
static int ext4_mb_pa_alloc(struct ext4_allocation_context *ac)
|
|
|
|
{
|
|
|
|
struct ext4_prealloc_space *pa;
|
|
|
|
|
|
|
|
BUG_ON(ext4_pspace_cachep == NULL);
|
|
|
|
pa = kmem_cache_zalloc(ext4_pspace_cachep, GFP_NOFS);
|
|
|
|
if (!pa)
|
|
|
|
return -ENOMEM;
|
|
|
|
atomic_set(&pa->pa_count, 1);
|
|
|
|
ac->ac_pa = pa;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-03-25 08:13:35 +00:00
|
|
|
static void ext4_mb_pa_put_free(struct ext4_allocation_context *ac)
|
2020-05-20 06:40:32 +00:00
|
|
|
{
|
|
|
|
struct ext4_prealloc_space *pa = ac->ac_pa;
|
|
|
|
|
|
|
|
BUG_ON(!pa);
|
|
|
|
ac->ac_pa = NULL;
|
|
|
|
WARN_ON(!atomic_dec_and_test(&pa->pa_count));
|
2023-03-25 08:13:35 +00:00
|
|
|
/*
|
|
|
|
* current function is only called due to an error or due to
|
|
|
|
* len of found blocks < len of requested blocks hence the PA has not
|
|
|
|
* been added to grp->bb_prealloc_list. So we don't need to lock it
|
|
|
|
*/
|
|
|
|
pa->pa_deleted = 1;
|
|
|
|
ext4_mb_pa_free(pa);
|
2020-05-20 06:40:32 +00:00
|
|
|
}
|
|
|
|
|
2009-09-18 17:38:55 +00:00
|
|
|
#ifdef CONFIG_EXT4_DEBUG
|
2020-05-10 06:24:42 +00:00
|
|
|
static inline void ext4_mb_show_pa(struct super_block *sb)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
2020-05-10 06:24:42 +00:00
|
|
|
ext4_group_t i, ngroups;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2023-06-16 16:50:51 +00:00
|
|
|
if (ext4_forced_shutdown(sb))
|
2010-07-27 15:56:08 +00:00
|
|
|
return;
|
|
|
|
|
2009-05-01 12:50:38 +00:00
|
|
|
ngroups = ext4_get_groups_count(sb);
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "groups: ");
|
2009-05-01 12:50:38 +00:00
|
|
|
for (i = 0; i < ngroups; i++) {
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_group_info *grp = ext4_get_group_info(sb, i);
|
|
|
|
struct ext4_prealloc_space *pa;
|
|
|
|
ext4_grpblk_t start;
|
|
|
|
struct list_head *cur;
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
|
|
|
|
if (!grp)
|
|
|
|
continue;
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_lock_group(sb, i);
|
|
|
|
list_for_each(cur, &grp->bb_prealloc_list) {
|
|
|
|
pa = list_entry(cur, struct ext4_prealloc_space,
|
|
|
|
pa_group_list);
|
|
|
|
spin_lock(&pa->pa_lock);
|
|
|
|
ext4_get_group_no_and_offset(sb, pa->pa_pstart,
|
|
|
|
NULL, &start);
|
|
|
|
spin_unlock(&pa->pa_lock);
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "PA:%u:%d:%d\n", i, start,
|
|
|
|
pa->pa_len);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2008-04-30 01:59:59 +00:00
|
|
|
ext4_unlock_group(sb, i);
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "%u: %d/%d\n", i, grp->bb_free,
|
|
|
|
grp->bb_fragments);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
}
|
2020-05-10 06:24:42 +00:00
|
|
|
|
|
|
|
static void ext4_mb_show_ac(struct ext4_allocation_context *ac)
|
|
|
|
{
|
|
|
|
struct super_block *sb = ac->ac_sb;
|
|
|
|
|
2023-06-16 16:50:51 +00:00
|
|
|
if (ext4_forced_shutdown(sb))
|
2020-05-10 06:24:42 +00:00
|
|
|
return;
|
|
|
|
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "Can't allocate:"
|
2020-05-10 06:24:42 +00:00
|
|
|
" Allocation context details:");
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "status %u flags 0x%x",
|
2020-05-10 06:24:42 +00:00
|
|
|
ac->ac_status, ac->ac_flags);
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "orig %lu/%lu/%lu@%lu, "
|
2020-05-10 06:24:42 +00:00
|
|
|
"goal %lu/%lu/%lu@%lu, "
|
|
|
|
"best %lu/%lu/%lu@%lu cr %d",
|
|
|
|
(unsigned long)ac->ac_o_ex.fe_group,
|
|
|
|
(unsigned long)ac->ac_o_ex.fe_start,
|
|
|
|
(unsigned long)ac->ac_o_ex.fe_len,
|
|
|
|
(unsigned long)ac->ac_o_ex.fe_logical,
|
|
|
|
(unsigned long)ac->ac_g_ex.fe_group,
|
|
|
|
(unsigned long)ac->ac_g_ex.fe_start,
|
|
|
|
(unsigned long)ac->ac_g_ex.fe_len,
|
|
|
|
(unsigned long)ac->ac_g_ex.fe_logical,
|
|
|
|
(unsigned long)ac->ac_b_ex.fe_group,
|
|
|
|
(unsigned long)ac->ac_b_ex.fe_start,
|
|
|
|
(unsigned long)ac->ac_b_ex.fe_len,
|
|
|
|
(unsigned long)ac->ac_b_ex.fe_logical,
|
|
|
|
(int)ac->ac_criteria);
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "%u found", ac->ac_found);
|
2024-10-21 10:00:57 +00:00
|
|
|
mb_debug(sb, "used pa: %s, ", str_yes_no(ac->ac_pa));
|
2023-05-30 12:33:40 +00:00
|
|
|
if (ac->ac_pa)
|
|
|
|
mb_debug(sb, "pa_type %s\n", ac->ac_pa->pa_type == MB_GROUP_PA ?
|
|
|
|
"group pa" : "inode pa");
|
2020-05-10 06:24:42 +00:00
|
|
|
ext4_mb_show_pa(sb);
|
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
#else
|
2020-05-10 06:24:42 +00:00
|
|
|
static inline void ext4_mb_show_pa(struct super_block *sb)
|
|
|
|
{
|
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
static inline void ext4_mb_show_ac(struct ext4_allocation_context *ac)
|
|
|
|
{
|
2020-05-10 06:24:42 +00:00
|
|
|
ext4_mb_show_pa(ac->ac_sb);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We use locality group preallocation for small size file. The size of the
|
|
|
|
* file is determined by the current size or the resulting size after
|
|
|
|
* allocation which ever is larger
|
|
|
|
*
|
2009-03-31 13:11:14 +00:00
|
|
|
* One can tune this size via /sys/fs/ext4/<partition>/mb_stream_req
|
2008-01-29 05:19:52 +00:00
|
|
|
*/
|
|
|
|
static void ext4_mb_group_or_file(struct ext4_allocation_context *ac)
|
|
|
|
{
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(ac->ac_sb);
|
|
|
|
int bsbits = ac->ac_sb->s_blocksize_bits;
|
|
|
|
loff_t size, isize;
|
2022-09-08 09:21:27 +00:00
|
|
|
bool inode_pa_eligible, group_pa_eligible;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
if (!(ac->ac_flags & EXT4_MB_HINT_DATA))
|
|
|
|
return;
|
|
|
|
|
2009-08-10 02:01:13 +00:00
|
|
|
if (unlikely(ac->ac_flags & EXT4_MB_HINT_GOAL_ONLY))
|
|
|
|
return;
|
|
|
|
|
2022-09-08 09:21:27 +00:00
|
|
|
group_pa_eligible = sbi->s_mb_group_prealloc > 0;
|
|
|
|
inode_pa_eligible = true;
|
2023-07-24 12:10:57 +00:00
|
|
|
size = extent_logical_end(sbi, &ac->ac_o_ex);
|
ext4: Avoid group preallocation for closed files
Currently the group preallocation code tries to find a large (512)
free block from which to do per-cpu group allocation for small files.
The problem with this scheme is that it leaves the filesystem horribly
fragmented. In the worst case, if the filesystem is unmounted and
remounted (after a system shutdown, for example) we forget the fact
that wee were using a particular (now-partially filled) 512 block
extent. So the next time we try to allocate space for a small file,
we will find *another* completely free 512 block chunk to allocate
small files. Given that there are 32,768 blocks in a block group,
after 64 iterations of "mount, write one 4k file in a directory,
unmount", the block group will have 64 files, each separated by 511
blocks, and the block group will no longer have any free 512
completely free chunks of blocks for group preallocation space.
So if we try to allocate blocks for a file that has been closed, such
that we know the final size of the file, and the filesystem is not
busy, avoid using group preallocation.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2009-09-18 17:34:02 +00:00
|
|
|
isize = (i_size_read(ac->ac_inode) + ac->ac_sb->s_blocksize - 1)
|
|
|
|
>> bsbits;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2022-09-08 09:21:27 +00:00
|
|
|
/* No point in using inode preallocation for closed files */
|
2019-02-11 04:04:16 +00:00
|
|
|
if ((size == isize) && !ext4_fs_is_busy(sbi) &&
|
2022-09-08 09:21:27 +00:00
|
|
|
!inode_is_open_for_write(ac->ac_inode))
|
|
|
|
inode_pa_eligible = false;
|
ext4: Avoid group preallocation for closed files
Currently the group preallocation code tries to find a large (512)
free block from which to do per-cpu group allocation for small files.
The problem with this scheme is that it leaves the filesystem horribly
fragmented. In the worst case, if the filesystem is unmounted and
remounted (after a system shutdown, for example) we forget the fact
that wee were using a particular (now-partially filled) 512 block
extent. So the next time we try to allocate space for a small file,
we will find *another* completely free 512 block chunk to allocate
small files. Given that there are 32,768 blocks in a block group,
after 64 iterations of "mount, write one 4k file in a directory,
unmount", the block group will have 64 files, each separated by 511
blocks, and the block group will no longer have any free 512
completely free chunks of blocks for group preallocation space.
So if we try to allocate blocks for a file that has been closed, such
that we know the final size of the file, and the filesystem is not
busy, avoid using group preallocation.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2009-09-18 17:34:02 +00:00
|
|
|
|
2009-09-28 04:06:20 +00:00
|
|
|
size = max(size, isize);
|
2022-09-08 09:21:27 +00:00
|
|
|
/* Don't use group allocation for large files */
|
|
|
|
if (size > sbi->s_mb_stream_request)
|
|
|
|
group_pa_eligible = false;
|
|
|
|
|
|
|
|
if (!group_pa_eligible) {
|
|
|
|
if (inode_pa_eligible)
|
|
|
|
ac->ac_flags |= EXT4_MB_STREAM_ALLOC;
|
|
|
|
else
|
|
|
|
ac->ac_flags |= EXT4_MB_HINT_NOPREALLOC;
|
2008-01-29 05:19:52 +00:00
|
|
|
return;
|
2009-08-10 02:01:13 +00:00
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
BUG_ON(ac->ac_lg != NULL);
|
|
|
|
/*
|
|
|
|
* locality group prealloc space are per cpu. The reason for having
|
|
|
|
* per cpu locality group is to reduce the contention between block
|
|
|
|
* request from multiple CPUs.
|
|
|
|
*/
|
2014-08-17 17:30:28 +00:00
|
|
|
ac->ac_lg = raw_cpu_ptr(sbi->s_locality_groups);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
/* we're going to use group allocation */
|
|
|
|
ac->ac_flags |= EXT4_MB_HINT_GROUP_ALLOC;
|
|
|
|
|
|
|
|
/* serialize all allocations in the group */
|
|
|
|
mutex_lock(&ac->ac_lg->lg_mutex);
|
|
|
|
}
|
|
|
|
|
2022-12-02 12:04:09 +00:00
|
|
|
static noinline_for_stack void
|
2008-04-29 12:11:12 +00:00
|
|
|
ext4_mb_initialize_context(struct ext4_allocation_context *ac,
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_allocation_request *ar)
|
|
|
|
{
|
|
|
|
struct super_block *sb = ar->inode->i_sb;
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
|
|
|
struct ext4_super_block *es = sbi->s_es;
|
|
|
|
ext4_group_t group;
|
2008-11-05 05:14:04 +00:00
|
|
|
unsigned int len;
|
|
|
|
ext4_fsblk_t goal;
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_grpblk_t block;
|
|
|
|
|
|
|
|
/* we can't allocate > group size */
|
|
|
|
len = ar->len;
|
|
|
|
|
|
|
|
/* just a dirty hack to filter too big requests */
|
ext4: optimize mballoc for large allocations
The ext4 block allocator only maintains buddy bitmaps for chunks which
are less than or equal to one quarter of a block group. That is, for
a file aystem with a 1k blocksize, and where the number of blocks in a
block group is 8192 blocks, the largest chunk size tracked by buddy
bitmaps is 2048 blocks.
For a file system with a 4k blocksize, and where the number of blocks
in a block group is 32768 blocks, the largest chunk size tracked by
buddy bitmaps is 8192 blocks.
To work around this code, mballoc.c before this commit would truncate
allocation requests to the number of blocks in a block group minus 10.
Why 10? Aside from being a completely arbitrary number, it avoids
block allocation to be a power of two larger than 25% of the block
group. If you try to explicitly fallocate 50% of the block group
size, this will demonstrate the problem; the block allocation code
will scan the all of the blocks in the file system with cr==0 (since
the request is for a natural power of two), but then completely fail
for all blocks groups, since the buddy bitmaps don't track chunk sizes
of 50% of the block group.
To fix this, in these we use ext4_mb_complex_scan_group() instead of
ext4_mb_simple_scan_group().
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: Andreas Dilger <adilger@dilger.ca>
2013-02-04 20:08:40 +00:00
|
|
|
if (len >= EXT4_CLUSTERS_PER_GROUP(sb))
|
|
|
|
len = EXT4_CLUSTERS_PER_GROUP(sb);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
|
|
|
/* start searching from the goal */
|
|
|
|
goal = ar->goal;
|
|
|
|
if (goal < le32_to_cpu(es->s_first_data_block) ||
|
|
|
|
goal >= ext4_blocks_count(es))
|
|
|
|
goal = le32_to_cpu(es->s_first_data_block);
|
|
|
|
ext4_get_group_no_and_offset(sb, goal, &group, &block);
|
|
|
|
|
|
|
|
/* set up allocation goals */
|
2013-12-20 14:29:35 +00:00
|
|
|
ac->ac_b_ex.fe_logical = EXT4_LBLK_CMASK(sbi, ar->logical);
|
2008-01-29 05:19:52 +00:00
|
|
|
ac->ac_status = AC_STATUS_CONTINUE;
|
|
|
|
ac->ac_sb = sb;
|
|
|
|
ac->ac_inode = ar->inode;
|
2011-09-09 22:48:51 +00:00
|
|
|
ac->ac_o_ex.fe_logical = ac->ac_b_ex.fe_logical;
|
2008-01-29 05:19:52 +00:00
|
|
|
ac->ac_o_ex.fe_group = group;
|
|
|
|
ac->ac_o_ex.fe_start = block;
|
|
|
|
ac->ac_o_ex.fe_len = len;
|
2011-09-09 22:48:51 +00:00
|
|
|
ac->ac_g_ex = ac->ac_o_ex;
|
2023-05-30 12:33:49 +00:00
|
|
|
ac->ac_orig_goal_len = ac->ac_g_ex.fe_len;
|
2008-01-29 05:19:52 +00:00
|
|
|
ac->ac_flags = ar->flags;
|
|
|
|
|
2020-07-15 03:00:44 +00:00
|
|
|
/* we have to define context: we'll work with a file or
|
2008-01-29 05:19:52 +00:00
|
|
|
* locality group. this is a policy, actually */
|
|
|
|
ext4_mb_group_or_file(ac);
|
|
|
|
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "init ac: %u blocks @ %u, goal %u, flags 0x%x, 2^%d, "
|
2008-01-29 05:19:52 +00:00
|
|
|
"left: %u/%u, right %u/%u to %swritable\n",
|
|
|
|
(unsigned) ar->len, (unsigned) ar->logical,
|
|
|
|
(unsigned) ar->goal, ac->ac_flags, ac->ac_2order,
|
|
|
|
(unsigned) ar->lleft, (unsigned) ar->pleft,
|
|
|
|
(unsigned) ar->lright, (unsigned) ar->pright,
|
2019-02-11 04:04:16 +00:00
|
|
|
inode_is_open_for_write(ar->inode) ? "" : "non-");
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
2008-07-23 18:14:05 +00:00
|
|
|
static noinline_for_stack void
|
|
|
|
ext4_mb_discard_lg_preallocations(struct super_block *sb,
|
|
|
|
struct ext4_locality_group *lg,
|
|
|
|
int order, int total_entries)
|
|
|
|
{
|
|
|
|
ext4_group_t group = 0;
|
|
|
|
struct ext4_buddy e4b;
|
2023-08-12 07:18:39 +00:00
|
|
|
LIST_HEAD(discard_list);
|
2008-07-23 18:14:05 +00:00
|
|
|
struct ext4_prealloc_space *pa, *tmp;
|
|
|
|
|
2020-05-10 06:24:54 +00:00
|
|
|
mb_debug(sb, "discard locality group preallocation\n");
|
2008-07-23 18:14:05 +00:00
|
|
|
|
|
|
|
spin_lock(&lg->lg_prealloc_lock);
|
|
|
|
list_for_each_entry_rcu(pa, &lg->lg_prealloc_list[order],
|
2023-03-25 08:13:40 +00:00
|
|
|
pa_node.lg_list,
|
2020-02-13 15:25:58 +00:00
|
|
|
lockdep_is_held(&lg->lg_prealloc_lock)) {
|
2008-07-23 18:14:05 +00:00
|
|
|
spin_lock(&pa->pa_lock);
|
|
|
|
if (atomic_read(&pa->pa_count)) {
|
|
|
|
/*
|
|
|
|
* This is the pa that we just used
|
|
|
|
* for block allocation. So don't
|
|
|
|
* free that
|
|
|
|
*/
|
|
|
|
spin_unlock(&pa->pa_lock);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (pa->pa_deleted) {
|
|
|
|
spin_unlock(&pa->pa_lock);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
/* only lg prealloc space */
|
2009-03-27 21:16:58 +00:00
|
|
|
BUG_ON(pa->pa_type != MB_GROUP_PA);
|
2008-07-23 18:14:05 +00:00
|
|
|
|
|
|
|
/* seems this one can be freed ... */
|
2020-08-17 07:36:15 +00:00
|
|
|
ext4_mb_mark_pa_deleted(sb, pa);
|
2008-07-23 18:14:05 +00:00
|
|
|
spin_unlock(&pa->pa_lock);
|
|
|
|
|
2023-03-25 08:13:40 +00:00
|
|
|
list_del_rcu(&pa->pa_node.lg_list);
|
2008-07-23 18:14:05 +00:00
|
|
|
list_add(&pa->u.pa_tmp_list, &discard_list);
|
|
|
|
|
|
|
|
total_entries--;
|
|
|
|
if (total_entries <= 5) {
|
|
|
|
/*
|
|
|
|
* we want to keep only 5 entries
|
|
|
|
* allowing it to grow to 8. This
|
|
|
|
* mak sure we don't call discard
|
|
|
|
* soon for this list.
|
|
|
|
*/
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
spin_unlock(&lg->lg_prealloc_lock);
|
|
|
|
|
|
|
|
list_for_each_entry_safe(pa, tmp, &discard_list, u.pa_tmp_list) {
|
2017-05-22 02:35:23 +00:00
|
|
|
int err;
|
2008-07-23 18:14:05 +00:00
|
|
|
|
2013-04-04 03:32:34 +00:00
|
|
|
group = ext4_get_group_number(sb, pa->pa_pstart);
|
2017-05-22 02:35:23 +00:00
|
|
|
err = ext4_mb_load_buddy_gfp(sb, group, &e4b,
|
|
|
|
GFP_NOFS|__GFP_NOFAIL);
|
|
|
|
if (err) {
|
2020-03-28 23:33:43 +00:00
|
|
|
ext4_error_err(sb, -err, "Error %d loading buddy information for %u",
|
|
|
|
err, group);
|
2008-07-23 18:14:05 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
ext4_lock_group(sb, group);
|
|
|
|
list_del(&pa->pa_group_list);
|
2010-10-28 01:30:07 +00:00
|
|
|
ext4_mb_release_group_pa(&e4b, pa);
|
2008-07-23 18:14:05 +00:00
|
|
|
ext4_unlock_group(sb, group);
|
|
|
|
|
2010-05-14 04:00:00 +00:00
|
|
|
ext4_mb_unload_buddy(&e4b);
|
2008-07-23 18:14:05 +00:00
|
|
|
list_del(&pa->u.pa_tmp_list);
|
|
|
|
call_rcu(&(pa)->u.pa_rcu, ext4_mb_pa_callback);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We have incremented pa_count. So it cannot be freed at this
|
|
|
|
* point. Also we hold lg_mutex. So no parallel allocation is
|
|
|
|
* possible from this lg. That means pa_free cannot be updated.
|
|
|
|
*
|
|
|
|
* A parallel ext4_mb_discard_group_preallocations is possible.
|
|
|
|
* which can cause the lg_prealloc_list to be updated.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static void ext4_mb_add_n_trim(struct ext4_allocation_context *ac)
|
|
|
|
{
|
|
|
|
int order, added = 0, lg_prealloc_count = 1;
|
|
|
|
struct super_block *sb = ac->ac_sb;
|
|
|
|
struct ext4_locality_group *lg = ac->ac_lg;
|
|
|
|
struct ext4_prealloc_space *tmp_pa, *pa = ac->ac_pa;
|
|
|
|
|
|
|
|
order = fls(pa->pa_free) - 1;
|
|
|
|
if (order > PREALLOC_TB_SIZE - 1)
|
|
|
|
/* The max size of hash table is PREALLOC_TB_SIZE */
|
|
|
|
order = PREALLOC_TB_SIZE - 1;
|
|
|
|
/* Add the prealloc space to lg */
|
2013-02-02 02:31:27 +00:00
|
|
|
spin_lock(&lg->lg_prealloc_lock);
|
2008-07-23 18:14:05 +00:00
|
|
|
list_for_each_entry_rcu(tmp_pa, &lg->lg_prealloc_list[order],
|
2023-03-25 08:13:40 +00:00
|
|
|
pa_node.lg_list,
|
2020-02-13 15:25:58 +00:00
|
|
|
lockdep_is_held(&lg->lg_prealloc_lock)) {
|
2008-07-23 18:14:05 +00:00
|
|
|
spin_lock(&tmp_pa->pa_lock);
|
|
|
|
if (tmp_pa->pa_deleted) {
|
2009-03-27 23:43:21 +00:00
|
|
|
spin_unlock(&tmp_pa->pa_lock);
|
2008-07-23 18:14:05 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!added && pa->pa_free < tmp_pa->pa_free) {
|
|
|
|
/* Add to the tail of the previous entry */
|
2023-03-25 08:13:40 +00:00
|
|
|
list_add_tail_rcu(&pa->pa_node.lg_list,
|
|
|
|
&tmp_pa->pa_node.lg_list);
|
2008-07-23 18:14:05 +00:00
|
|
|
added = 1;
|
|
|
|
/*
|
|
|
|
* we want to count the total
|
|
|
|
* number of entries in the list
|
|
|
|
*/
|
|
|
|
}
|
|
|
|
spin_unlock(&tmp_pa->pa_lock);
|
|
|
|
lg_prealloc_count++;
|
|
|
|
}
|
|
|
|
if (!added)
|
2023-03-25 08:13:40 +00:00
|
|
|
list_add_tail_rcu(&pa->pa_node.lg_list,
|
2008-07-23 18:14:05 +00:00
|
|
|
&lg->lg_prealloc_list[order]);
|
2013-02-02 02:31:27 +00:00
|
|
|
spin_unlock(&lg->lg_prealloc_lock);
|
2008-07-23 18:14:05 +00:00
|
|
|
|
|
|
|
/* Now trim the list to be not more than 8 elements */
|
2023-08-01 14:31:59 +00:00
|
|
|
if (lg_prealloc_count > 8)
|
2008-07-23 18:14:05 +00:00
|
|
|
ext4_mb_discard_lg_preallocations(sb, lg,
|
2013-02-02 02:31:27 +00:00
|
|
|
order, lg_prealloc_count);
|
2008-07-23 18:14:05 +00:00
|
|
|
}
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
/*
|
|
|
|
* release all resource we used in allocation
|
|
|
|
*/
|
2024-01-05 09:20:56 +00:00
|
|
|
static void ext4_mb_release_context(struct ext4_allocation_context *ac)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
2011-09-09 22:48:51 +00:00
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(ac->ac_sb);
|
2008-07-23 18:14:05 +00:00
|
|
|
struct ext4_prealloc_space *pa = ac->ac_pa;
|
|
|
|
if (pa) {
|
2009-03-27 21:16:58 +00:00
|
|
|
if (pa->pa_type == MB_GROUP_PA) {
|
2008-01-29 05:19:52 +00:00
|
|
|
/* see comment in ext4_mb_use_group_pa() */
|
2008-07-23 18:14:05 +00:00
|
|
|
spin_lock(&pa->pa_lock);
|
2011-09-09 22:48:51 +00:00
|
|
|
pa->pa_pstart += EXT4_C2B(sbi, ac->ac_b_ex.fe_len);
|
|
|
|
pa->pa_lstart += EXT4_C2B(sbi, ac->ac_b_ex.fe_len);
|
2008-07-23 18:14:05 +00:00
|
|
|
pa->pa_free -= ac->ac_b_ex.fe_len;
|
|
|
|
pa->pa_len -= ac->ac_b_ex.fe_len;
|
|
|
|
spin_unlock(&pa->pa_lock);
|
2020-08-17 07:36:06 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We want to add the pa to the right bucket.
|
|
|
|
* Remove it from the list and while adding
|
|
|
|
* make sure the list to which we are adding
|
|
|
|
* doesn't grow big.
|
|
|
|
*/
|
|
|
|
if (likely(pa->pa_free)) {
|
2023-03-25 08:13:40 +00:00
|
|
|
spin_lock(pa->pa_node_lock.lg_lock);
|
|
|
|
list_del_rcu(&pa->pa_node.lg_list);
|
|
|
|
spin_unlock(pa->pa_node_lock.lg_lock);
|
2020-08-17 07:36:06 +00:00
|
|
|
ext4_mb_add_n_trim(ac);
|
|
|
|
}
|
2009-02-10 16:14:34 +00:00
|
|
|
}
|
2020-08-17 07:36:15 +00:00
|
|
|
|
2009-02-10 16:14:34 +00:00
|
|
|
ext4_mb_put_pa(ac, ac->ac_sb, pa);
|
|
|
|
}
|
2024-04-16 17:28:57 +00:00
|
|
|
if (ac->ac_bitmap_folio)
|
|
|
|
folio_put(ac->ac_bitmap_folio);
|
2024-04-16 17:28:58 +00:00
|
|
|
if (ac->ac_buddy_folio)
|
|
|
|
folio_put(ac->ac_buddy_folio);
|
2008-01-29 05:19:52 +00:00
|
|
|
if (ac->ac_flags & EXT4_MB_HINT_GROUP_ALLOC)
|
|
|
|
mutex_unlock(&ac->ac_lg->lg_mutex);
|
|
|
|
ext4_mb_collect_stats(ac);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int ext4_mb_discard_preallocations(struct super_block *sb, int needed)
|
|
|
|
{
|
2009-05-01 12:50:38 +00:00
|
|
|
ext4_group_t i, ngroups = ext4_get_groups_count(sb);
|
2008-01-29 05:19:52 +00:00
|
|
|
int ret;
|
ext4: fix a possible ABBA deadlock due to busy PA
We found on older kernel (3.10) that in the scenario of insufficient
disk space, system may trigger an ABBA deadlock problem, it seems that
this problem still exists in latest kernel, try to fix it here. The
main process triggered by this problem is that task A occupies the PA
and waits for the jbd2 transaction finish, the jbd2 transaction waits
for the completion of task B's IO (plug_list), but task B waits for
the release of PA by task A to finish discard, which indirectly forms
an ABBA deadlock. The related calltrace is as follows:
Task A
vfs_write
ext4_mb_new_blocks()
ext4_mb_mark_diskspace_used() JBD2
jbd2_journal_get_write_access() -> jbd2_journal_commit_transaction()
->schedule() filemap_fdatawait()
| |
| Task B |
| do_unlinkat() |
| ext4_evict_inode() |
| jbd2_journal_begin_ordered_truncate() |
| filemap_fdatawrite_range() |
| ext4_mb_new_blocks() |
-ext4_mb_discard_group_preallocations() <-----
Here, try to cancel ext4_mb_discard_group_preallocations() internal
retry due to PA busy, and do a limited number of retries inside
ext4_mb_discard_preallocations(), which can circumvent the above
problems, but also has some advantages:
1. Since the PA is in a busy state, if other groups have free PAs,
keeping the current PA may help to reduce fragmentation.
2. Continue to traverse forward instead of waiting for the current
group PA to be released. In most scenarios, the PA discard time
can be reduced.
However, in the case of smaller free space, if only a few groups have
space, then due to multiple traversals of the group, it may increase
CPU overhead. But in contrast, I feel that the overall benefit is
better than the cost.
Signed-off-by: Chunguang Xu <brookxu@tencent.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/1637630277-23496-1-git-send-email-brookxu.cn@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
2021-11-23 01:17:57 +00:00
|
|
|
int freed = 0, busy = 0;
|
|
|
|
int retry = 0;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2009-06-17 15:48:11 +00:00
|
|
|
trace_ext4_mb_discard_preallocations(sb, needed);
|
ext4: fix a possible ABBA deadlock due to busy PA
We found on older kernel (3.10) that in the scenario of insufficient
disk space, system may trigger an ABBA deadlock problem, it seems that
this problem still exists in latest kernel, try to fix it here. The
main process triggered by this problem is that task A occupies the PA
and waits for the jbd2 transaction finish, the jbd2 transaction waits
for the completion of task B's IO (plug_list), but task B waits for
the release of PA by task A to finish discard, which indirectly forms
an ABBA deadlock. The related calltrace is as follows:
Task A
vfs_write
ext4_mb_new_blocks()
ext4_mb_mark_diskspace_used() JBD2
jbd2_journal_get_write_access() -> jbd2_journal_commit_transaction()
->schedule() filemap_fdatawait()
| |
| Task B |
| do_unlinkat() |
| ext4_evict_inode() |
| jbd2_journal_begin_ordered_truncate() |
| filemap_fdatawrite_range() |
| ext4_mb_new_blocks() |
-ext4_mb_discard_group_preallocations() <-----
Here, try to cancel ext4_mb_discard_group_preallocations() internal
retry due to PA busy, and do a limited number of retries inside
ext4_mb_discard_preallocations(), which can circumvent the above
problems, but also has some advantages:
1. Since the PA is in a busy state, if other groups have free PAs,
keeping the current PA may help to reduce fragmentation.
2. Continue to traverse forward instead of waiting for the current
group PA to be released. In most scenarios, the PA discard time
can be reduced.
However, in the case of smaller free space, if only a few groups have
space, then due to multiple traversals of the group, it may increase
CPU overhead. But in contrast, I feel that the overall benefit is
better than the cost.
Signed-off-by: Chunguang Xu <brookxu@tencent.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/1637630277-23496-1-git-send-email-brookxu.cn@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
2021-11-23 01:17:57 +00:00
|
|
|
|
|
|
|
if (needed == 0)
|
|
|
|
needed = EXT4_CLUSTERS_PER_GROUP(sb) + 1;
|
|
|
|
repeat:
|
2009-05-01 12:50:38 +00:00
|
|
|
for (i = 0; i < ngroups && needed > 0; i++) {
|
ext4: fix a possible ABBA deadlock due to busy PA
We found on older kernel (3.10) that in the scenario of insufficient
disk space, system may trigger an ABBA deadlock problem, it seems that
this problem still exists in latest kernel, try to fix it here. The
main process triggered by this problem is that task A occupies the PA
and waits for the jbd2 transaction finish, the jbd2 transaction waits
for the completion of task B's IO (plug_list), but task B waits for
the release of PA by task A to finish discard, which indirectly forms
an ABBA deadlock. The related calltrace is as follows:
Task A
vfs_write
ext4_mb_new_blocks()
ext4_mb_mark_diskspace_used() JBD2
jbd2_journal_get_write_access() -> jbd2_journal_commit_transaction()
->schedule() filemap_fdatawait()
| |
| Task B |
| do_unlinkat() |
| ext4_evict_inode() |
| jbd2_journal_begin_ordered_truncate() |
| filemap_fdatawrite_range() |
| ext4_mb_new_blocks() |
-ext4_mb_discard_group_preallocations() <-----
Here, try to cancel ext4_mb_discard_group_preallocations() internal
retry due to PA busy, and do a limited number of retries inside
ext4_mb_discard_preallocations(), which can circumvent the above
problems, but also has some advantages:
1. Since the PA is in a busy state, if other groups have free PAs,
keeping the current PA may help to reduce fragmentation.
2. Continue to traverse forward instead of waiting for the current
group PA to be released. In most scenarios, the PA discard time
can be reduced.
However, in the case of smaller free space, if only a few groups have
space, then due to multiple traversals of the group, it may increase
CPU overhead. But in contrast, I feel that the overall benefit is
better than the cost.
Signed-off-by: Chunguang Xu <brookxu@tencent.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/1637630277-23496-1-git-send-email-brookxu.cn@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
2021-11-23 01:17:57 +00:00
|
|
|
ret = ext4_mb_discard_group_preallocations(sb, i, &busy);
|
2008-01-29 05:19:52 +00:00
|
|
|
freed += ret;
|
|
|
|
needed -= ret;
|
ext4: fix a possible ABBA deadlock due to busy PA
We found on older kernel (3.10) that in the scenario of insufficient
disk space, system may trigger an ABBA deadlock problem, it seems that
this problem still exists in latest kernel, try to fix it here. The
main process triggered by this problem is that task A occupies the PA
and waits for the jbd2 transaction finish, the jbd2 transaction waits
for the completion of task B's IO (plug_list), but task B waits for
the release of PA by task A to finish discard, which indirectly forms
an ABBA deadlock. The related calltrace is as follows:
Task A
vfs_write
ext4_mb_new_blocks()
ext4_mb_mark_diskspace_used() JBD2
jbd2_journal_get_write_access() -> jbd2_journal_commit_transaction()
->schedule() filemap_fdatawait()
| |
| Task B |
| do_unlinkat() |
| ext4_evict_inode() |
| jbd2_journal_begin_ordered_truncate() |
| filemap_fdatawrite_range() |
| ext4_mb_new_blocks() |
-ext4_mb_discard_group_preallocations() <-----
Here, try to cancel ext4_mb_discard_group_preallocations() internal
retry due to PA busy, and do a limited number of retries inside
ext4_mb_discard_preallocations(), which can circumvent the above
problems, but also has some advantages:
1. Since the PA is in a busy state, if other groups have free PAs,
keeping the current PA may help to reduce fragmentation.
2. Continue to traverse forward instead of waiting for the current
group PA to be released. In most scenarios, the PA discard time
can be reduced.
However, in the case of smaller free space, if only a few groups have
space, then due to multiple traversals of the group, it may increase
CPU overhead. But in contrast, I feel that the overall benefit is
better than the cost.
Signed-off-by: Chunguang Xu <brookxu@tencent.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/1637630277-23496-1-git-send-email-brookxu.cn@gmail.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
2021-11-23 01:17:57 +00:00
|
|
|
cond_resched();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (needed > 0 && busy && ++retry < 3) {
|
|
|
|
busy = 0;
|
|
|
|
goto repeat;
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return freed;
|
|
|
|
}
|
|
|
|
|
2020-05-20 06:40:33 +00:00
|
|
|
static bool ext4_mb_discard_preallocations_should_retry(struct super_block *sb,
|
ext4: mballoc: introduce pcpu seqcnt for freeing PA to improve ENOSPC handling
There could be a race in function ext4_mb_discard_group_preallocations()
where the 1st thread may iterate through group's bb_prealloc_list and
remove all the PAs and add to function's local list head.
Now if the 2nd thread comes in to discard the group preallocations,
it will see that the group->bb_prealloc_list is empty and will return 0.
Consider for a case where we have less number of groups
(for e.g. just group 0),
this may even return an -ENOSPC error from ext4_mb_new_blocks()
(where we call for ext4_mb_discard_group_preallocations()).
But that is wrong, since 2nd thread should have waited for 1st thread
to release all the PAs and should have retried for allocation.
Since 1st thread was anyway going to discard the PAs.
The algorithm using this percpu seq counter goes below:
1. We sample the percpu discard_pa_seq counter before trying for block
allocation in ext4_mb_new_blocks().
2. We increment this percpu discard_pa_seq counter when we either allocate
or free these blocks i.e. while marking those blocks as used/free in
mb_mark_used()/mb_free_blocks().
3. We also increment this percpu seq counter when we successfully identify
that the bb_prealloc_list is not empty and hence proceed for discarding
of those PAs inside ext4_mb_discard_group_preallocations().
Now to make sure that the regular fast path of block allocation is not
affected, as a small optimization we only sample the percpu seq counter
on that cpu. Only when the block allocation fails and when freed blocks
found were 0, that is when we sample percpu seq counter for all cpus using
below function ext4_get_discard_pa_seq_sum(). This happens after making
sure that all the PAs on grp->bb_prealloc_list got freed or if it's empty.
It can be well argued that why don't just check for grp->bb_free to
see if there are any free blocks to be allocated. So here are the two
concerns which were discussed:-
1. If for some reason the blocks available in the group are not
appropriate for allocation logic (say for e.g.
EXT4_MB_HINT_GOAL_ONLY, although this is not yet implemented), then
the retry logic may result into infinte looping since grp->bb_free is
non-zero.
2. Also before preallocation was clubbed with block allocation with the
same ext4_lock_group() held, there were lot of races where grp->bb_free
could not be reliably relied upon.
Due to above, this patch considers discard_pa_seq logic to determine if
we should retry for block allocation. Say if there are are n threads
trying for block allocation and none of those could allocate or discard
any of the blocks, then all of those n threads will fail the block
allocation and return -ENOSPC error. (Since the seq counter for all of
those will match as no block allocation/discard was done during that
duration).
Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
Link: https://lore.kernel.org/r/7f254686903b87c419d798742fd9a1be34f0657b.1589955723.git.riteshh@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2020-05-20 06:40:34 +00:00
|
|
|
struct ext4_allocation_context *ac, u64 *seq)
|
2020-05-20 06:40:33 +00:00
|
|
|
{
|
|
|
|
int freed;
|
ext4: mballoc: introduce pcpu seqcnt for freeing PA to improve ENOSPC handling
There could be a race in function ext4_mb_discard_group_preallocations()
where the 1st thread may iterate through group's bb_prealloc_list and
remove all the PAs and add to function's local list head.
Now if the 2nd thread comes in to discard the group preallocations,
it will see that the group->bb_prealloc_list is empty and will return 0.
Consider for a case where we have less number of groups
(for e.g. just group 0),
this may even return an -ENOSPC error from ext4_mb_new_blocks()
(where we call for ext4_mb_discard_group_preallocations()).
But that is wrong, since 2nd thread should have waited for 1st thread
to release all the PAs and should have retried for allocation.
Since 1st thread was anyway going to discard the PAs.
The algorithm using this percpu seq counter goes below:
1. We sample the percpu discard_pa_seq counter before trying for block
allocation in ext4_mb_new_blocks().
2. We increment this percpu discard_pa_seq counter when we either allocate
or free these blocks i.e. while marking those blocks as used/free in
mb_mark_used()/mb_free_blocks().
3. We also increment this percpu seq counter when we successfully identify
that the bb_prealloc_list is not empty and hence proceed for discarding
of those PAs inside ext4_mb_discard_group_preallocations().
Now to make sure that the regular fast path of block allocation is not
affected, as a small optimization we only sample the percpu seq counter
on that cpu. Only when the block allocation fails and when freed blocks
found were 0, that is when we sample percpu seq counter for all cpus using
below function ext4_get_discard_pa_seq_sum(). This happens after making
sure that all the PAs on grp->bb_prealloc_list got freed or if it's empty.
It can be well argued that why don't just check for grp->bb_free to
see if there are any free blocks to be allocated. So here are the two
concerns which were discussed:-
1. If for some reason the blocks available in the group are not
appropriate for allocation logic (say for e.g.
EXT4_MB_HINT_GOAL_ONLY, although this is not yet implemented), then
the retry logic may result into infinte looping since grp->bb_free is
non-zero.
2. Also before preallocation was clubbed with block allocation with the
same ext4_lock_group() held, there were lot of races where grp->bb_free
could not be reliably relied upon.
Due to above, this patch considers discard_pa_seq logic to determine if
we should retry for block allocation. Say if there are are n threads
trying for block allocation and none of those could allocate or discard
any of the blocks, then all of those n threads will fail the block
allocation and return -ENOSPC error. (Since the seq counter for all of
those will match as no block allocation/discard was done during that
duration).
Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
Link: https://lore.kernel.org/r/7f254686903b87c419d798742fd9a1be34f0657b.1589955723.git.riteshh@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2020-05-20 06:40:34 +00:00
|
|
|
u64 seq_retry = 0;
|
|
|
|
bool ret = false;
|
2020-05-20 06:40:33 +00:00
|
|
|
|
|
|
|
freed = ext4_mb_discard_preallocations(sb, ac->ac_o_ex.fe_len);
|
ext4: mballoc: introduce pcpu seqcnt for freeing PA to improve ENOSPC handling
There could be a race in function ext4_mb_discard_group_preallocations()
where the 1st thread may iterate through group's bb_prealloc_list and
remove all the PAs and add to function's local list head.
Now if the 2nd thread comes in to discard the group preallocations,
it will see that the group->bb_prealloc_list is empty and will return 0.
Consider for a case where we have less number of groups
(for e.g. just group 0),
this may even return an -ENOSPC error from ext4_mb_new_blocks()
(where we call for ext4_mb_discard_group_preallocations()).
But that is wrong, since 2nd thread should have waited for 1st thread
to release all the PAs and should have retried for allocation.
Since 1st thread was anyway going to discard the PAs.
The algorithm using this percpu seq counter goes below:
1. We sample the percpu discard_pa_seq counter before trying for block
allocation in ext4_mb_new_blocks().
2. We increment this percpu discard_pa_seq counter when we either allocate
or free these blocks i.e. while marking those blocks as used/free in
mb_mark_used()/mb_free_blocks().
3. We also increment this percpu seq counter when we successfully identify
that the bb_prealloc_list is not empty and hence proceed for discarding
of those PAs inside ext4_mb_discard_group_preallocations().
Now to make sure that the regular fast path of block allocation is not
affected, as a small optimization we only sample the percpu seq counter
on that cpu. Only when the block allocation fails and when freed blocks
found were 0, that is when we sample percpu seq counter for all cpus using
below function ext4_get_discard_pa_seq_sum(). This happens after making
sure that all the PAs on grp->bb_prealloc_list got freed or if it's empty.
It can be well argued that why don't just check for grp->bb_free to
see if there are any free blocks to be allocated. So here are the two
concerns which were discussed:-
1. If for some reason the blocks available in the group are not
appropriate for allocation logic (say for e.g.
EXT4_MB_HINT_GOAL_ONLY, although this is not yet implemented), then
the retry logic may result into infinte looping since grp->bb_free is
non-zero.
2. Also before preallocation was clubbed with block allocation with the
same ext4_lock_group() held, there were lot of races where grp->bb_free
could not be reliably relied upon.
Due to above, this patch considers discard_pa_seq logic to determine if
we should retry for block allocation. Say if there are are n threads
trying for block allocation and none of those could allocate or discard
any of the blocks, then all of those n threads will fail the block
allocation and return -ENOSPC error. (Since the seq counter for all of
those will match as no block allocation/discard was done during that
duration).
Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
Link: https://lore.kernel.org/r/7f254686903b87c419d798742fd9a1be34f0657b.1589955723.git.riteshh@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2020-05-20 06:40:34 +00:00
|
|
|
if (freed) {
|
|
|
|
ret = true;
|
|
|
|
goto out_dbg;
|
|
|
|
}
|
|
|
|
seq_retry = ext4_get_discard_pa_seq_sum();
|
2020-05-20 06:40:36 +00:00
|
|
|
if (!(ac->ac_flags & EXT4_MB_STRICT_CHECK) || seq_retry != *seq) {
|
|
|
|
ac->ac_flags |= EXT4_MB_STRICT_CHECK;
|
ext4: mballoc: introduce pcpu seqcnt for freeing PA to improve ENOSPC handling
There could be a race in function ext4_mb_discard_group_preallocations()
where the 1st thread may iterate through group's bb_prealloc_list and
remove all the PAs and add to function's local list head.
Now if the 2nd thread comes in to discard the group preallocations,
it will see that the group->bb_prealloc_list is empty and will return 0.
Consider for a case where we have less number of groups
(for e.g. just group 0),
this may even return an -ENOSPC error from ext4_mb_new_blocks()
(where we call for ext4_mb_discard_group_preallocations()).
But that is wrong, since 2nd thread should have waited for 1st thread
to release all the PAs and should have retried for allocation.
Since 1st thread was anyway going to discard the PAs.
The algorithm using this percpu seq counter goes below:
1. We sample the percpu discard_pa_seq counter before trying for block
allocation in ext4_mb_new_blocks().
2. We increment this percpu discard_pa_seq counter when we either allocate
or free these blocks i.e. while marking those blocks as used/free in
mb_mark_used()/mb_free_blocks().
3. We also increment this percpu seq counter when we successfully identify
that the bb_prealloc_list is not empty and hence proceed for discarding
of those PAs inside ext4_mb_discard_group_preallocations().
Now to make sure that the regular fast path of block allocation is not
affected, as a small optimization we only sample the percpu seq counter
on that cpu. Only when the block allocation fails and when freed blocks
found were 0, that is when we sample percpu seq counter for all cpus using
below function ext4_get_discard_pa_seq_sum(). This happens after making
sure that all the PAs on grp->bb_prealloc_list got freed or if it's empty.
It can be well argued that why don't just check for grp->bb_free to
see if there are any free blocks to be allocated. So here are the two
concerns which were discussed:-
1. If for some reason the blocks available in the group are not
appropriate for allocation logic (say for e.g.
EXT4_MB_HINT_GOAL_ONLY, although this is not yet implemented), then
the retry logic may result into infinte looping since grp->bb_free is
non-zero.
2. Also before preallocation was clubbed with block allocation with the
same ext4_lock_group() held, there were lot of races where grp->bb_free
could not be reliably relied upon.
Due to above, this patch considers discard_pa_seq logic to determine if
we should retry for block allocation. Say if there are are n threads
trying for block allocation and none of those could allocate or discard
any of the blocks, then all of those n threads will fail the block
allocation and return -ENOSPC error. (Since the seq counter for all of
those will match as no block allocation/discard was done during that
duration).
Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
Link: https://lore.kernel.org/r/7f254686903b87c419d798742fd9a1be34f0657b.1589955723.git.riteshh@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2020-05-20 06:40:34 +00:00
|
|
|
*seq = seq_retry;
|
|
|
|
ret = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
out_dbg:
|
2024-10-07 17:20:06 +00:00
|
|
|
mb_debug(sb, "freed %d, retry ? %s\n", freed, str_yes_no(ret));
|
ext4: mballoc: introduce pcpu seqcnt for freeing PA to improve ENOSPC handling
There could be a race in function ext4_mb_discard_group_preallocations()
where the 1st thread may iterate through group's bb_prealloc_list and
remove all the PAs and add to function's local list head.
Now if the 2nd thread comes in to discard the group preallocations,
it will see that the group->bb_prealloc_list is empty and will return 0.
Consider for a case where we have less number of groups
(for e.g. just group 0),
this may even return an -ENOSPC error from ext4_mb_new_blocks()
(where we call for ext4_mb_discard_group_preallocations()).
But that is wrong, since 2nd thread should have waited for 1st thread
to release all the PAs and should have retried for allocation.
Since 1st thread was anyway going to discard the PAs.
The algorithm using this percpu seq counter goes below:
1. We sample the percpu discard_pa_seq counter before trying for block
allocation in ext4_mb_new_blocks().
2. We increment this percpu discard_pa_seq counter when we either allocate
or free these blocks i.e. while marking those blocks as used/free in
mb_mark_used()/mb_free_blocks().
3. We also increment this percpu seq counter when we successfully identify
that the bb_prealloc_list is not empty and hence proceed for discarding
of those PAs inside ext4_mb_discard_group_preallocations().
Now to make sure that the regular fast path of block allocation is not
affected, as a small optimization we only sample the percpu seq counter
on that cpu. Only when the block allocation fails and when freed blocks
found were 0, that is when we sample percpu seq counter for all cpus using
below function ext4_get_discard_pa_seq_sum(). This happens after making
sure that all the PAs on grp->bb_prealloc_list got freed or if it's empty.
It can be well argued that why don't just check for grp->bb_free to
see if there are any free blocks to be allocated. So here are the two
concerns which were discussed:-
1. If for some reason the blocks available in the group are not
appropriate for allocation logic (say for e.g.
EXT4_MB_HINT_GOAL_ONLY, although this is not yet implemented), then
the retry logic may result into infinte looping since grp->bb_free is
non-zero.
2. Also before preallocation was clubbed with block allocation with the
same ext4_lock_group() held, there were lot of races where grp->bb_free
could not be reliably relied upon.
Due to above, this patch considers discard_pa_seq logic to determine if
we should retry for block allocation. Say if there are are n threads
trying for block allocation and none of those could allocate or discard
any of the blocks, then all of those n threads will fail the block
allocation and return -ENOSPC error. (Since the seq counter for all of
those will match as no block allocation/discard was done during that
duration).
Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
Link: https://lore.kernel.org/r/7f254686903b87c419d798742fd9a1be34f0657b.1589955723.git.riteshh@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2020-05-20 06:40:34 +00:00
|
|
|
return ret;
|
2020-05-20 06:40:33 +00:00
|
|
|
}
|
|
|
|
|
2023-06-03 15:03:17 +00:00
|
|
|
/*
|
|
|
|
* Simple allocator for Ext4 fast commit replay path. It searches for blocks
|
|
|
|
* linearly starting at the goal block and also excludes the blocks which
|
|
|
|
* are going to be in use after fast commit replay.
|
|
|
|
*/
|
|
|
|
static ext4_fsblk_t
|
|
|
|
ext4_mb_new_blocks_simple(struct ext4_allocation_request *ar, int *errp)
|
|
|
|
{
|
|
|
|
struct buffer_head *bitmap_bh;
|
|
|
|
struct super_block *sb = ar->inode->i_sb;
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
|
|
|
ext4_group_t group, nr;
|
|
|
|
ext4_grpblk_t blkoff;
|
|
|
|
ext4_grpblk_t max = EXT4_CLUSTERS_PER_GROUP(sb);
|
|
|
|
ext4_grpblk_t i = 0;
|
|
|
|
ext4_fsblk_t goal, block;
|
2023-07-07 11:59:07 +00:00
|
|
|
struct ext4_super_block *es = sbi->s_es;
|
2023-06-03 15:03:17 +00:00
|
|
|
|
|
|
|
goal = ar->goal;
|
|
|
|
if (goal < le32_to_cpu(es->s_first_data_block) ||
|
|
|
|
goal >= ext4_blocks_count(es))
|
|
|
|
goal = le32_to_cpu(es->s_first_data_block);
|
|
|
|
|
|
|
|
ar->len = 0;
|
|
|
|
ext4_get_group_no_and_offset(sb, goal, &group, &blkoff);
|
|
|
|
for (nr = ext4_get_groups_count(sb); nr > 0; nr--) {
|
|
|
|
bitmap_bh = ext4_read_block_bitmap(sb, group);
|
|
|
|
if (IS_ERR(bitmap_bh)) {
|
|
|
|
*errp = PTR_ERR(bitmap_bh);
|
|
|
|
pr_warn("Failed to read block bitmap\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
i = mb_find_next_zero_bit(bitmap_bh->b_data, max,
|
|
|
|
blkoff);
|
|
|
|
if (i >= max)
|
|
|
|
break;
|
|
|
|
if (ext4_fc_replay_check_excluded(sb,
|
|
|
|
ext4_group_first_block_no(sb, group) +
|
|
|
|
EXT4_C2B(sbi, i))) {
|
|
|
|
blkoff = i + 1;
|
|
|
|
} else
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
brelse(bitmap_bh);
|
|
|
|
if (i < max)
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (++group >= ext4_get_groups_count(sb))
|
|
|
|
group = 0;
|
|
|
|
|
|
|
|
blkoff = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (i >= max) {
|
|
|
|
*errp = -ENOSPC;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
block = ext4_group_first_block_no(sb, group) + EXT4_C2B(sbi, i);
|
2023-09-28 16:03:56 +00:00
|
|
|
ext4_mb_mark_bb(sb, block, 1, true);
|
2023-06-03 15:03:17 +00:00
|
|
|
ar->len = 1;
|
|
|
|
|
2024-04-17 18:10:40 +00:00
|
|
|
*errp = 0;
|
2023-06-03 15:03:17 +00:00
|
|
|
return block;
|
|
|
|
}
|
2020-10-15 20:37:59 +00:00
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
/*
|
|
|
|
* Main entry point into mballoc to allocate blocks
|
|
|
|
* it tries to use preallocation first, then falls back
|
|
|
|
* to usual allocation
|
|
|
|
*/
|
|
|
|
ext4_fsblk_t ext4_mb_new_blocks(handle_t *handle,
|
2010-08-05 20:22:24 +00:00
|
|
|
struct ext4_allocation_request *ar, int *errp)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
2008-02-10 06:13:33 +00:00
|
|
|
struct ext4_allocation_context *ac = NULL;
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_sb_info *sbi;
|
|
|
|
struct super_block *sb;
|
|
|
|
ext4_fsblk_t block = 0;
|
2009-01-22 17:13:05 +00:00
|
|
|
unsigned int inquota = 0;
|
2011-09-09 22:48:51 +00:00
|
|
|
unsigned int reserv_clstrs = 0;
|
ext4: limit the number of retries after discarding preallocations blocks
This patch avoids threads live-locking for hours when a large number
threads are competing over the last few free extents as they blocks
getting added and removed from preallocation pools. From our bug
reporter:
A reliable way for triggering this has multiple writers
continuously write() to files when the filesystem is full, while
small amounts of space are freed (e.g. by truncating a large file
-1MiB at a time). In the local filesystem, this can be done by
simply not checking the return code of write (0) and/or the error
(ENOSPACE) that is set. Over NFS with an async mount, even clients
with proper error checking will behave this way since the linux NFS
client implementation will not propagate the server errors [the
write syscalls immediately return success] until the file handle is
closed. This leads to a situation where NFS clients send a
continuous stream of WRITE rpcs which result in ERRNOSPACE -- but
since the client isn't seeing this, the stream of writes continues
at maximum network speed.
When some space does appear, multiple writers will all attempt to
claim it for their current write. For NFS, we may see dozens to
hundreds of threads that do this.
The real-world scenario of this is database backup tooling (in
particular, github.com/mdkent/percona-xtrabackup) which may write
large files (>1TiB) to NFS for safe keeping. Some temporary files
are written, rewound, and read back -- all before closing the file
handle (the temp file is actually unlinked, to trigger automatic
deletion on close/crash.) An application like this operating on an
async NFS mount will not see an error code until TiB have been
written/read.
The lockup was observed when running this database backup on large
filesystems (64 TiB in this case) with a high number of block
groups and no free space. Fragmentation is generally not a factor
in this filesystem (~thousands of large files, mostly contiguous
except for the parts written while the filesystem is at capacity.)
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
2022-09-01 22:03:14 +00:00
|
|
|
int retries = 0;
|
ext4: mballoc: introduce pcpu seqcnt for freeing PA to improve ENOSPC handling
There could be a race in function ext4_mb_discard_group_preallocations()
where the 1st thread may iterate through group's bb_prealloc_list and
remove all the PAs and add to function's local list head.
Now if the 2nd thread comes in to discard the group preallocations,
it will see that the group->bb_prealloc_list is empty and will return 0.
Consider for a case where we have less number of groups
(for e.g. just group 0),
this may even return an -ENOSPC error from ext4_mb_new_blocks()
(where we call for ext4_mb_discard_group_preallocations()).
But that is wrong, since 2nd thread should have waited for 1st thread
to release all the PAs and should have retried for allocation.
Since 1st thread was anyway going to discard the PAs.
The algorithm using this percpu seq counter goes below:
1. We sample the percpu discard_pa_seq counter before trying for block
allocation in ext4_mb_new_blocks().
2. We increment this percpu discard_pa_seq counter when we either allocate
or free these blocks i.e. while marking those blocks as used/free in
mb_mark_used()/mb_free_blocks().
3. We also increment this percpu seq counter when we successfully identify
that the bb_prealloc_list is not empty and hence proceed for discarding
of those PAs inside ext4_mb_discard_group_preallocations().
Now to make sure that the regular fast path of block allocation is not
affected, as a small optimization we only sample the percpu seq counter
on that cpu. Only when the block allocation fails and when freed blocks
found were 0, that is when we sample percpu seq counter for all cpus using
below function ext4_get_discard_pa_seq_sum(). This happens after making
sure that all the PAs on grp->bb_prealloc_list got freed or if it's empty.
It can be well argued that why don't just check for grp->bb_free to
see if there are any free blocks to be allocated. So here are the two
concerns which were discussed:-
1. If for some reason the blocks available in the group are not
appropriate for allocation logic (say for e.g.
EXT4_MB_HINT_GOAL_ONLY, although this is not yet implemented), then
the retry logic may result into infinte looping since grp->bb_free is
non-zero.
2. Also before preallocation was clubbed with block allocation with the
same ext4_lock_group() held, there were lot of races where grp->bb_free
could not be reliably relied upon.
Due to above, this patch considers discard_pa_seq logic to determine if
we should retry for block allocation. Say if there are are n threads
trying for block allocation and none of those could allocate or discard
any of the blocks, then all of those n threads will fail the block
allocation and return -ENOSPC error. (Since the seq counter for all of
those will match as no block allocation/discard was done during that
duration).
Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
Link: https://lore.kernel.org/r/7f254686903b87c419d798742fd9a1be34f0657b.1589955723.git.riteshh@linux.ibm.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2020-05-20 06:40:34 +00:00
|
|
|
u64 seq;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2013-04-04 02:00:52 +00:00
|
|
|
might_sleep();
|
2008-01-29 05:19:52 +00:00
|
|
|
sb = ar->inode->i_sb;
|
|
|
|
sbi = EXT4_SB(sb);
|
|
|
|
|
2009-06-17 15:48:11 +00:00
|
|
|
trace_ext4_request_blocks(ar);
|
2020-10-15 20:37:59 +00:00
|
|
|
if (sbi->s_mount_state & EXT4_FC_REPLAY)
|
2023-06-03 15:03:17 +00:00
|
|
|
return ext4_mb_new_blocks_simple(ar, errp);
|
2009-01-04 01:03:21 +00:00
|
|
|
|
2011-10-21 00:07:23 +00:00
|
|
|
/* Allow to use superuser reservation for quota file */
|
2017-06-22 15:31:25 +00:00
|
|
|
if (ext4_is_quota_file(ar->inode))
|
2011-10-21 00:07:23 +00:00
|
|
|
ar->flags |= EXT4_MB_USE_ROOT_BLOCKS;
|
|
|
|
|
2014-09-04 22:07:25 +00:00
|
|
|
if ((ar->flags & EXT4_MB_DELALLOC_RESERVED) == 0) {
|
2009-01-22 17:13:05 +00:00
|
|
|
/* Without delayed allocation we need to verify
|
|
|
|
* there is enough free blocks to do block allocation
|
|
|
|
* and verify allocation doesn't exceed the quota limits.
|
2008-07-14 21:52:37 +00:00
|
|
|
*/
|
2011-05-25 11:41:26 +00:00
|
|
|
while (ar->len &&
|
2011-09-09 23:14:51 +00:00
|
|
|
ext4_claim_free_clusters(sbi, ar->len, ar->flags)) {
|
2011-05-25 11:41:26 +00:00
|
|
|
|
2008-09-09 03:14:50 +00:00
|
|
|
/* let others to free the space */
|
2013-03-11 02:28:09 +00:00
|
|
|
cond_resched();
|
2008-09-09 03:14:50 +00:00
|
|
|
ar->len = ar->len >> 1;
|
|
|
|
}
|
|
|
|
if (!ar->len) {
|
2020-05-10 06:24:43 +00:00
|
|
|
ext4_mb_show_pa(sb);
|
2008-10-09 14:56:23 +00:00
|
|
|
*errp = -ENOSPC;
|
|
|
|
return 0;
|
|
|
|
}
|
2011-09-09 22:48:51 +00:00
|
|
|
reserv_clstrs = ar->len;
|
2011-05-25 11:41:26 +00:00
|
|
|
if (ar->flags & EXT4_MB_USE_ROOT_BLOCKS) {
|
2011-09-09 22:48:51 +00:00
|
|
|
dquot_alloc_block_nofail(ar->inode,
|
|
|
|
EXT4_C2B(sbi, ar->len));
|
2011-05-25 11:41:26 +00:00
|
|
|
} else {
|
|
|
|
while (ar->len &&
|
2011-09-09 22:48:51 +00:00
|
|
|
dquot_alloc_block(ar->inode,
|
|
|
|
EXT4_C2B(sbi, ar->len))) {
|
2011-05-25 11:41:26 +00:00
|
|
|
|
|
|
|
ar->flags |= EXT4_MB_HINT_NOPREALLOC;
|
|
|
|
ar->len--;
|
|
|
|
}
|
2009-01-22 17:13:05 +00:00
|
|
|
}
|
|
|
|
inquota = ar->len;
|
|
|
|
if (ar->len == 0) {
|
|
|
|
*errp = -EDQUOT;
|
2010-08-05 20:22:24 +00:00
|
|
|
goto out;
|
2009-01-22 17:13:05 +00:00
|
|
|
}
|
2008-07-11 23:27:31 +00:00
|
|
|
}
|
2008-07-14 21:52:37 +00:00
|
|
|
|
2012-09-27 00:43:37 +00:00
|
|
|
ac = kmem_cache_zalloc(ext4_ac_cachep, GFP_NOFS);
|
2009-07-13 13:45:52 +00:00
|
|
|
if (!ac) {
|
2008-07-11 23:27:31 +00:00
|
|
|
ar->len = 0;
|
2008-02-10 06:13:33 +00:00
|
|
|
*errp = -ENOMEM;
|
2010-08-05 20:22:24 +00:00
|
|
|
goto out;
|
2008-02-10 06:13:33 +00:00
|
|
|
}
|
|
|
|
|
2022-12-02 12:04:09 +00:00
|
|
|
ext4_mb_initialize_context(ac, ar);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2008-02-10 06:13:33 +00:00
|
|
|
ac->ac_op = EXT4_MB_HISTORY_PREALLOC;
|
2020-06-09 10:53:10 +00:00
|
|
|
seq = this_cpu_read(discard_pa_seq);
|
2008-02-10 06:13:33 +00:00
|
|
|
if (!ext4_mb_use_preallocated(ac)) {
|
|
|
|
ac->ac_op = EXT4_MB_HISTORY_ALLOC;
|
|
|
|
ext4_mb_normalize_request(ac, ar);
|
2020-05-20 06:40:32 +00:00
|
|
|
|
|
|
|
*errp = ext4_mb_pa_alloc(ac);
|
|
|
|
if (*errp)
|
|
|
|
goto errout;
|
2008-01-29 05:19:52 +00:00
|
|
|
repeat:
|
|
|
|
/* allocate space in core */
|
2010-08-05 20:22:24 +00:00
|
|
|
*errp = ext4_mb_regular_allocator(ac);
|
2020-05-20 06:40:32 +00:00
|
|
|
/*
|
|
|
|
* pa allocated above is added to grp->bb_prealloc_list only
|
|
|
|
* when we were able to allocate some block i.e. when
|
|
|
|
* ac->ac_status == AC_STATUS_FOUND.
|
|
|
|
* And error from above mean ac->ac_status != AC_STATUS_FOUND
|
|
|
|
* So we have to free this pa here itself.
|
|
|
|
*/
|
2013-07-01 12:12:36 +00:00
|
|
|
if (*errp) {
|
2023-03-25 08:13:35 +00:00
|
|
|
ext4_mb_pa_put_free(ac);
|
2013-07-01 12:12:36 +00:00
|
|
|
ext4_discard_allocated_blocks(ac);
|
|
|
|
goto errout;
|
|
|
|
}
|
2020-05-20 06:40:32 +00:00
|
|
|
if (ac->ac_status == AC_STATUS_FOUND &&
|
|
|
|
ac->ac_o_ex.fe_len >= ac->ac_f_ex.fe_len)
|
2023-03-25 08:13:35 +00:00
|
|
|
ext4_mb_pa_put_free(ac);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2008-02-10 06:13:33 +00:00
|
|
|
if (likely(ac->ac_status == AC_STATUS_FOUND)) {
|
2011-09-09 22:48:51 +00:00
|
|
|
*errp = ext4_mb_mark_diskspace_used(ac, handle, reserv_clstrs);
|
2016-07-15 03:02:47 +00:00
|
|
|
if (*errp) {
|
2009-12-09 03:18:25 +00:00
|
|
|
ext4_discard_allocated_blocks(ac);
|
2012-11-08 16:11:59 +00:00
|
|
|
goto errout;
|
|
|
|
} else {
|
2008-05-15 18:43:20 +00:00
|
|
|
block = ext4_grp_offs_to_block(sb, &ac->ac_b_ex);
|
|
|
|
ar->len = ac->ac_b_ex.fe_len;
|
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
} else {
|
ext4: limit the number of retries after discarding preallocations blocks
This patch avoids threads live-locking for hours when a large number
threads are competing over the last few free extents as they blocks
getting added and removed from preallocation pools. From our bug
reporter:
A reliable way for triggering this has multiple writers
continuously write() to files when the filesystem is full, while
small amounts of space are freed (e.g. by truncating a large file
-1MiB at a time). In the local filesystem, this can be done by
simply not checking the return code of write (0) and/or the error
(ENOSPACE) that is set. Over NFS with an async mount, even clients
with proper error checking will behave this way since the linux NFS
client implementation will not propagate the server errors [the
write syscalls immediately return success] until the file handle is
closed. This leads to a situation where NFS clients send a
continuous stream of WRITE rpcs which result in ERRNOSPACE -- but
since the client isn't seeing this, the stream of writes continues
at maximum network speed.
When some space does appear, multiple writers will all attempt to
claim it for their current write. For NFS, we may see dozens to
hundreds of threads that do this.
The real-world scenario of this is database backup tooling (in
particular, github.com/mdkent/percona-xtrabackup) which may write
large files (>1TiB) to NFS for safe keeping. Some temporary files
are written, rewound, and read back -- all before closing the file
handle (the temp file is actually unlinked, to trigger automatic
deletion on close/crash.) An application like this operating on an
async NFS mount will not see an error code until TiB have been
written/read.
The lockup was observed when running this database backup on large
filesystems (64 TiB in this case) with a high number of block
groups and no free space. Fragmentation is generally not a factor
in this filesystem (~thousands of large files, mostly contiguous
except for the parts written while the filesystem is at capacity.)
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@kernel.org
2022-09-01 22:03:14 +00:00
|
|
|
if (++retries < 3 &&
|
|
|
|
ext4_mb_discard_preallocations_should_retry(sb, ac, &seq))
|
2008-01-29 05:19:52 +00:00
|
|
|
goto repeat;
|
2020-05-20 06:40:32 +00:00
|
|
|
/*
|
|
|
|
* If block allocation fails then the pa allocated above
|
|
|
|
* needs to be freed here itself.
|
|
|
|
*/
|
2023-03-25 08:13:35 +00:00
|
|
|
ext4_mb_pa_put_free(ac);
|
2008-01-29 05:19:52 +00:00
|
|
|
*errp = -ENOSPC;
|
2010-08-05 20:22:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (*errp) {
|
2023-03-03 17:21:11 +00:00
|
|
|
errout:
|
2008-02-10 06:13:33 +00:00
|
|
|
ac->ac_b_ex.fe_len = 0;
|
2008-01-29 05:19:52 +00:00
|
|
|
ar->len = 0;
|
2008-02-10 06:13:33 +00:00
|
|
|
ext4_mb_show_ac(ac);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2008-02-10 06:13:33 +00:00
|
|
|
ext4_mb_release_context(ac);
|
2023-03-03 17:21:11 +00:00
|
|
|
kmem_cache_free(ext4_ac_cachep, ac);
|
2010-08-05 20:22:24 +00:00
|
|
|
out:
|
2009-01-22 17:13:05 +00:00
|
|
|
if (inquota && ar->len < inquota)
|
2011-09-09 22:48:51 +00:00
|
|
|
dquot_free_block(ar->inode, EXT4_C2B(sbi, inquota - ar->len));
|
2009-01-06 02:49:12 +00:00
|
|
|
if (!ar->len) {
|
2014-09-04 22:07:25 +00:00
|
|
|
if ((ar->flags & EXT4_MB_DELALLOC_RESERVED) == 0)
|
2009-01-06 02:49:12 +00:00
|
|
|
/* release all the reserved blocks if non delalloc */
|
2011-09-09 22:56:51 +00:00
|
|
|
percpu_counter_sub(&sbi->s_dirtyclusters_counter,
|
2011-09-09 22:48:51 +00:00
|
|
|
reserv_clstrs);
|
2009-01-06 02:49:12 +00:00
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2009-06-17 15:48:11 +00:00
|
|
|
trace_ext4_allocate_blocks(ar, (unsigned long long)block);
|
2009-01-04 01:03:21 +00:00
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
return block;
|
|
|
|
}
|
|
|
|
|
2008-10-16 14:14:27 +00:00
|
|
|
/*
|
|
|
|
* We can merge two free data extents only if the physical blocks
|
|
|
|
* are contiguous, AND the extents were freed by the same transaction,
|
|
|
|
* AND the blocks are associated with the same group.
|
|
|
|
*/
|
2017-06-23 03:54:33 +00:00
|
|
|
static void ext4_try_merge_freed_extent(struct ext4_sb_info *sbi,
|
|
|
|
struct ext4_free_data *entry,
|
|
|
|
struct ext4_free_data *new_entry,
|
|
|
|
struct rb_root *entry_rb_root)
|
2008-10-16 14:14:27 +00:00
|
|
|
{
|
2017-06-23 03:54:33 +00:00
|
|
|
if ((entry->efd_tid != new_entry->efd_tid) ||
|
|
|
|
(entry->efd_group != new_entry->efd_group))
|
|
|
|
return;
|
|
|
|
if (entry->efd_start_cluster + entry->efd_count ==
|
|
|
|
new_entry->efd_start_cluster) {
|
|
|
|
new_entry->efd_start_cluster = entry->efd_start_cluster;
|
|
|
|
new_entry->efd_count += entry->efd_count;
|
|
|
|
} else if (new_entry->efd_start_cluster + new_entry->efd_count ==
|
|
|
|
entry->efd_start_cluster) {
|
|
|
|
new_entry->efd_count += entry->efd_count;
|
|
|
|
} else
|
|
|
|
return;
|
|
|
|
spin_lock(&sbi->s_md_lock);
|
|
|
|
list_del(&entry->efd_list);
|
|
|
|
spin_unlock(&sbi->s_md_lock);
|
|
|
|
rb_erase(&entry->efd_node, entry_rb_root);
|
|
|
|
kmem_cache_free(ext4_free_data_cachep, entry);
|
2008-10-16 14:14:27 +00:00
|
|
|
}
|
|
|
|
|
2023-03-03 17:21:08 +00:00
|
|
|
static noinline_for_stack void
|
2008-04-29 12:11:12 +00:00
|
|
|
ext4_mb_free_metadata(handle_t *handle, struct ext4_buddy *e4b,
|
2009-01-06 02:36:55 +00:00
|
|
|
struct ext4_free_data *new_entry)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
2010-06-29 16:54:28 +00:00
|
|
|
ext4_group_t group = e4b->bd_group;
|
2011-09-09 22:50:51 +00:00
|
|
|
ext4_grpblk_t cluster;
|
2016-06-26 22:24:01 +00:00
|
|
|
ext4_grpblk_t clusters = new_entry->efd_count;
|
2009-01-06 02:36:55 +00:00
|
|
|
struct ext4_free_data *entry;
|
2008-01-29 05:19:52 +00:00
|
|
|
struct ext4_group_info *db = e4b->bd_info;
|
|
|
|
struct super_block *sb = e4b->bd_sb;
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
2008-10-16 14:14:27 +00:00
|
|
|
struct rb_node **n = &db->bb_free_root.rb_node, *node;
|
|
|
|
struct rb_node *parent = NULL, *new_node;
|
|
|
|
|
2009-01-07 05:06:22 +00:00
|
|
|
BUG_ON(!ext4_handle_valid(handle));
|
2024-04-16 17:28:54 +00:00
|
|
|
BUG_ON(e4b->bd_bitmap_folio == NULL);
|
2024-04-16 17:28:55 +00:00
|
|
|
BUG_ON(e4b->bd_buddy_folio == NULL);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2012-02-20 22:53:02 +00:00
|
|
|
new_node = &new_entry->efd_node;
|
|
|
|
cluster = new_entry->efd_start_cluster;
|
2008-10-16 14:14:27 +00:00
|
|
|
|
|
|
|
if (!*n) {
|
|
|
|
/* first free block exent. We need to
|
|
|
|
protect buddy cache from being freed,
|
|
|
|
* otherwise we'll refresh it from
|
|
|
|
* on-disk bitmap and lose not-yet-available
|
|
|
|
* blocks */
|
2024-04-16 17:28:55 +00:00
|
|
|
folio_get(e4b->bd_buddy_folio);
|
2024-04-16 17:28:54 +00:00
|
|
|
folio_get(e4b->bd_bitmap_folio);
|
2008-10-16 14:14:27 +00:00
|
|
|
}
|
|
|
|
while (*n) {
|
|
|
|
parent = *n;
|
2012-02-20 22:53:02 +00:00
|
|
|
entry = rb_entry(parent, struct ext4_free_data, efd_node);
|
|
|
|
if (cluster < entry->efd_start_cluster)
|
2008-10-16 14:14:27 +00:00
|
|
|
n = &(*n)->rb_left;
|
2012-02-20 22:53:02 +00:00
|
|
|
else if (cluster >= (entry->efd_start_cluster + entry->efd_count))
|
2008-10-16 14:14:27 +00:00
|
|
|
n = &(*n)->rb_right;
|
|
|
|
else {
|
2010-06-29 16:54:28 +00:00
|
|
|
ext4_grp_locked_error(sb, group, 0,
|
2011-09-09 22:50:51 +00:00
|
|
|
ext4_group_first_block_no(sb, group) +
|
|
|
|
EXT4_C2B(sbi, cluster),
|
2010-06-29 16:54:28 +00:00
|
|
|
"Block already on to-be-freed list");
|
2020-11-07 15:58:18 +00:00
|
|
|
kmem_cache_free(ext4_free_data_cachep, new_entry);
|
2023-03-03 17:21:08 +00:00
|
|
|
return;
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2008-10-16 14:14:27 +00:00
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2008-10-16 14:14:27 +00:00
|
|
|
rb_link_node(new_node, parent, n);
|
|
|
|
rb_insert_color(new_node, &db->bb_free_root);
|
|
|
|
|
|
|
|
/* Now try to see the extent can be merged to left and right */
|
|
|
|
node = rb_prev(new_node);
|
|
|
|
if (node) {
|
2012-02-20 22:53:02 +00:00
|
|
|
entry = rb_entry(node, struct ext4_free_data, efd_node);
|
2017-06-23 03:54:33 +00:00
|
|
|
ext4_try_merge_freed_extent(sbi, entry, new_entry,
|
|
|
|
&(db->bb_free_root));
|
2008-10-16 14:14:27 +00:00
|
|
|
}
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2008-10-16 14:14:27 +00:00
|
|
|
node = rb_next(new_node);
|
|
|
|
if (node) {
|
2012-02-20 22:53:02 +00:00
|
|
|
entry = rb_entry(node, struct ext4_free_data, efd_node);
|
2017-06-23 03:54:33 +00:00
|
|
|
ext4_try_merge_freed_extent(sbi, entry, new_entry,
|
|
|
|
&(db->bb_free_root));
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2017-06-23 03:54:33 +00:00
|
|
|
|
2016-06-26 22:24:01 +00:00
|
|
|
spin_lock(&sbi->s_md_lock);
|
2023-06-12 12:40:17 +00:00
|
|
|
list_add_tail(&new_entry->efd_list, &sbi->s_freed_data_list[new_entry->efd_tid & 1]);
|
2016-06-26 22:24:01 +00:00
|
|
|
sbi->s_mb_free_pending += clusters;
|
|
|
|
spin_unlock(&sbi->s_md_lock);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
2020-10-15 20:37:59 +00:00
|
|
|
static void ext4_free_blocks_simple(struct inode *inode, ext4_fsblk_t block,
|
|
|
|
unsigned long count)
|
|
|
|
{
|
|
|
|
struct super_block *sb = inode->i_sb;
|
|
|
|
ext4_group_t group;
|
|
|
|
ext4_grpblk_t blkoff;
|
|
|
|
|
|
|
|
ext4_get_group_no_and_offset(sb, block, &group, &blkoff);
|
2023-09-28 16:03:59 +00:00
|
|
|
ext4_mb_mark_context(NULL, sb, false, group, blkoff, count,
|
|
|
|
EXT4_MB_BITMAP_MARKED_CHECK |
|
|
|
|
EXT4_MB_SYNC_UPDATE,
|
|
|
|
NULL);
|
2020-10-15 20:37:59 +00:00
|
|
|
}
|
|
|
|
|
2009-11-22 12:44:56 +00:00
|
|
|
/**
|
2022-02-16 07:02:45 +00:00
|
|
|
* ext4_mb_clear_bb() -- helper function for freeing blocks.
|
|
|
|
* Used by ext4_free_blocks()
|
2009-11-22 12:44:56 +00:00
|
|
|
* @handle: handle for this transaction
|
|
|
|
* @inode: inode
|
2019-06-19 20:30:03 +00:00
|
|
|
* @block: starting physical block to be freed
|
|
|
|
* @count: number of blocks to be freed
|
2011-06-06 03:26:40 +00:00
|
|
|
* @flags: flags used by ext4_free_blocks
|
2008-01-29 05:19:52 +00:00
|
|
|
*/
|
2022-02-16 07:02:45 +00:00
|
|
|
static void ext4_mb_clear_bb(handle_t *handle, struct inode *inode,
|
|
|
|
ext4_fsblk_t block, unsigned long count,
|
|
|
|
int flags)
|
2008-01-29 05:19:52 +00:00
|
|
|
{
|
|
|
|
struct super_block *sb = inode->i_sb;
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
struct ext4_group_info *grp;
|
2008-11-05 05:14:04 +00:00
|
|
|
unsigned int overflow;
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_grpblk_t bit;
|
|
|
|
ext4_group_t block_group;
|
|
|
|
struct ext4_sb_info *sbi;
|
|
|
|
struct ext4_buddy e4b;
|
2011-09-09 22:50:51 +00:00
|
|
|
unsigned int count_clusters;
|
2008-01-29 05:19:52 +00:00
|
|
|
int err = 0;
|
2023-09-28 16:04:02 +00:00
|
|
|
int mark_flags = 0;
|
|
|
|
ext4_grpblk_t changed;
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2020-10-15 20:37:59 +00:00
|
|
|
sbi = EXT4_SB(sb);
|
|
|
|
|
2022-07-14 16:59:03 +00:00
|
|
|
if (!(flags & EXT4_FREE_BLOCKS_VALIDATED) &&
|
|
|
|
!ext4_inode_block_valid(inode, block, count)) {
|
|
|
|
ext4_error(sb, "Freeing blocks in system zone - "
|
|
|
|
"Block = %llu, count = %lu", block, count);
|
|
|
|
/* err = 0. ext4_std_error should be a no op */
|
2023-09-28 16:04:01 +00:00
|
|
|
goto error_out;
|
2022-07-14 16:59:03 +00:00
|
|
|
}
|
|
|
|
flags |= EXT4_FREE_BLOCKS_VALIDATED;
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
do_more:
|
|
|
|
overflow = 0;
|
|
|
|
ext4_get_group_no_and_offset(sb, block, &block_group, &bit);
|
|
|
|
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
grp = ext4_get_group_info(sb, block_group);
|
|
|
|
if (unlikely(!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp)))
|
ext4: mark block group as corrupt on block bitmap error
When we notice a block-bitmap corruption (because of device failure or
something else), we should mark this group as corrupt and prevent
further block allocations/deallocations from it. Currently, we end up
generating one error message for every block in the bitmap. This
potentially could make the system unstable as noticed in some
bugs. With this patch, the error will be printed only the first time
and mark the entire block group as corrupted. This prevents future
access allocations/deallocations from it.
Also tested by corrupting the block
bitmap and forcefully introducing the mb_free_blocks error:
(1) create a largefile (2Gb)
$ dd if=/dev/zero of=largefile oflag=direct bs=10485760 count=200
(2) umount filesystem. use dumpe2fs to see which block-bitmaps
are in use by largefile and note their block numbers
(3) use dd to zero-out the used block bitmaps
$ dd if=/dev/zero of=/dev/hdc4 bs=4096 seek=14 count=8 oflag=direct
(4) mount the FS and delete the largefile.
(5) recreate the largefile. verify that the new largefile does not
get any blocks from the groups marked as bad.
Without the patch, we will see mb_free_blocks error for each bit in
each zero'ed out bitmap at (4). With the patch, we only see the error
once per blockgroup:
[ 309.706803] EXT4-fs error (device sdb4): ext4_mb_generate_buddy:735: group 15: 32768 clusters in bitmap, 0 in gd. blk grp corrupted.
[ 309.720824] EXT4-fs error (device sdb4): ext4_mb_generate_buddy:735: group 14: 32768 clusters in bitmap, 0 in gd. blk grp corrupted.
[ 309.732858] EXT4-fs error (device sdb4) in ext4_free_blocks:4802: IO failure
[ 309.748321] EXT4-fs error (device sdb4): ext4_mb_generate_buddy:735: group 13: 32768 clusters in bitmap, 0 in gd. blk grp corrupted.
[ 309.760331] EXT4-fs error (device sdb4) in ext4_free_blocks:4802: IO failure
[ 309.769695] EXT4-fs error (device sdb4): ext4_mb_generate_buddy:735: group 12: 32768 clusters in bitmap, 0 in gd. blk grp corrupted.
[ 309.781721] EXT4-fs error (device sdb4) in ext4_free_blocks:4802: IO failure
[ 309.798166] EXT4-fs error (device sdb4): ext4_mb_generate_buddy:735: group 11: 32768 clusters in bitmap, 0 in gd. blk grp corrupted.
[ 309.810184] EXT4-fs error (device sdb4) in ext4_free_blocks:4802: IO failure
[ 309.819532] EXT4-fs error (device sdb4): ext4_mb_generate_buddy:735: group 10: 32768 clusters in bitmap, 0 in gd. blk grp corrupted.
Google-Bug-Id: 7258357
[darrick.wong@oracle.com]
Further modifications (by Darrick) to make more obvious that this corruption
bit applies to blocks only. Set the corruption flag if the block group bitmap
verification fails.
Original-author: Aditya Kali <adityakali@google.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2013-08-28 21:35:51 +00:00
|
|
|
return;
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
/*
|
|
|
|
* Check to see if we are freeing blocks across a group
|
|
|
|
* boundary.
|
|
|
|
*/
|
2011-09-09 22:50:51 +00:00
|
|
|
if (EXT4_C2B(sbi, bit) + count > EXT4_BLOCKS_PER_GROUP(sb)) {
|
|
|
|
overflow = EXT4_C2B(sbi, bit) + count -
|
|
|
|
EXT4_BLOCKS_PER_GROUP(sb);
|
2008-01-29 05:19:52 +00:00
|
|
|
count -= overflow;
|
2022-07-14 16:59:03 +00:00
|
|
|
/* The range changed so it's no longer validated */
|
|
|
|
flags &= ~EXT4_FREE_BLOCKS_VALIDATED;
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
2013-03-02 22:18:58 +00:00
|
|
|
count_clusters = EXT4_NUM_B2C(sbi, count);
|
2023-09-28 16:04:01 +00:00
|
|
|
trace_ext4_mballoc_free(sb, inode, block_group, bit, count_clusters);
|
|
|
|
|
|
|
|
/* __GFP_NOFAIL: retry infinitely, ignore TIF_MEMDIE and memcg limit. */
|
|
|
|
err = ext4_mb_load_buddy_gfp(sb, block_group, &e4b,
|
|
|
|
GFP_NOFS|__GFP_NOFAIL);
|
|
|
|
if (err)
|
|
|
|
goto error_out;
|
|
|
|
|
|
|
|
if (!(flags & EXT4_FREE_BLOCKS_VALIDATED) &&
|
|
|
|
!ext4_inode_block_valid(inode, block, count)) {
|
|
|
|
ext4_error(sb, "Freeing blocks in system zone - "
|
|
|
|
"Block = %llu, count = %lu", block, count);
|
|
|
|
/* err = 0. ext4_std_error should be a no op */
|
|
|
|
goto error_clean;
|
|
|
|
}
|
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
#ifdef AGGRESSIVE_CHECK
|
2023-09-28 16:04:02 +00:00
|
|
|
mark_flags |= EXT4_MB_BITMAP_MARKED_CHECK;
|
2008-01-29 05:19:52 +00:00
|
|
|
#endif
|
2023-09-28 16:04:02 +00:00
|
|
|
err = ext4_mb_mark_context(handle, sb, false, block_group, bit,
|
|
|
|
count_clusters, mark_flags, &changed);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2023-09-28 16:04:01 +00:00
|
|
|
|
2023-09-28 16:04:02 +00:00
|
|
|
if (err && changed == 0)
|
|
|
|
goto error_clean;
|
2023-09-28 16:04:01 +00:00
|
|
|
|
2023-09-28 16:04:02 +00:00
|
|
|
#ifdef AGGRESSIVE_CHECK
|
|
|
|
BUG_ON(changed != count_clusters);
|
|
|
|
#endif
|
2009-11-23 12:17:05 +00:00
|
|
|
|
2016-02-21 23:31:41 +00:00
|
|
|
/*
|
|
|
|
* We need to make sure we don't reuse the freed block until after the
|
|
|
|
* transaction is committed. We make an exception if the inode is to be
|
|
|
|
* written in writeback mode since writeback mode has weak data
|
|
|
|
* consistency guarantees.
|
|
|
|
*/
|
|
|
|
if (ext4_handle_valid(handle) &&
|
|
|
|
((flags & EXT4_FREE_BLOCKS_METADATA) ||
|
|
|
|
!ext4_should_writeback_data(inode))) {
|
2009-01-06 02:36:55 +00:00
|
|
|
struct ext4_free_data *new_entry;
|
|
|
|
/*
|
2015-07-05 16:33:44 +00:00
|
|
|
* We use __GFP_NOFAIL because ext4_free_blocks() is not allowed
|
|
|
|
* to fail.
|
2009-01-06 02:36:55 +00:00
|
|
|
*/
|
2015-07-05 16:33:44 +00:00
|
|
|
new_entry = kmem_cache_alloc(ext4_free_data_cachep,
|
|
|
|
GFP_NOFS|__GFP_NOFAIL);
|
2012-02-20 22:53:02 +00:00
|
|
|
new_entry->efd_start_cluster = bit;
|
|
|
|
new_entry->efd_group = block_group;
|
|
|
|
new_entry->efd_count = count_clusters;
|
|
|
|
new_entry->efd_tid = handle->h_transaction->t_tid;
|
2009-05-03 00:35:09 +00:00
|
|
|
|
2009-01-06 02:36:55 +00:00
|
|
|
ext4_lock_group(sb, block_group);
|
|
|
|
ext4_mb_free_metadata(handle, &e4b, new_entry);
|
2008-01-29 05:19:52 +00:00
|
|
|
} else {
|
2012-11-08 19:04:52 +00:00
|
|
|
if (test_opt(sb, DISCARD)) {
|
2023-06-03 15:03:18 +00:00
|
|
|
err = ext4_issue_discard(sb, block_group, bit,
|
2024-02-26 08:17:31 +00:00
|
|
|
count_clusters);
|
2024-02-13 10:16:01 +00:00
|
|
|
/*
|
|
|
|
* Ignore EOPNOTSUPP error. This is consistent with
|
|
|
|
* what happens when using journal.
|
|
|
|
*/
|
|
|
|
if (err == -EOPNOTSUPP)
|
|
|
|
err = 0;
|
|
|
|
if (err)
|
2012-11-08 19:04:52 +00:00
|
|
|
ext4_msg(sb, KERN_WARNING, "discard request in"
|
2022-02-16 07:02:50 +00:00
|
|
|
" group:%u block:%d count:%lu failed"
|
2012-11-08 19:04:52 +00:00
|
|
|
" with %d", block_group, bit, count,
|
|
|
|
err);
|
2024-08-17 08:55:10 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
EXT4_MB_GRP_CLEAR_TRIMMED(e4b.bd_info);
|
2012-11-08 19:04:52 +00:00
|
|
|
|
2009-05-03 00:35:09 +00:00
|
|
|
ext4_lock_group(sb, block_group);
|
2011-09-09 22:50:51 +00:00
|
|
|
mb_free_blocks(inode, &e4b, bit, count_clusters);
|
2008-01-29 05:19:52 +00:00
|
|
|
}
|
|
|
|
|
2009-05-03 00:35:09 +00:00
|
|
|
ext4_unlock_group(sb, block_group);
|
2008-01-29 05:19:52 +00:00
|
|
|
|
2018-10-01 18:25:08 +00:00
|
|
|
/*
|
|
|
|
* on a bigalloc file system, defer the s_freeclusters_counter
|
|
|
|
* update to the caller (ext4_remove_space and friends) so they
|
|
|
|
* can determine if a cluster freed here should be rereserved
|
|
|
|
*/
|
|
|
|
if (!(flags & EXT4_FREE_BLOCKS_RERESERVE_CLUSTER)) {
|
|
|
|
if (!(flags & EXT4_FREE_BLOCKS_NO_QUOT_UPDATE))
|
|
|
|
dquot_free_block(inode, EXT4_C2B(sbi, count_clusters));
|
|
|
|
percpu_counter_add(&sbi->s_freeclusters_counter,
|
|
|
|
count_clusters);
|
|
|
|
}
|
2013-08-17 13:36:54 +00:00
|
|
|
|
2008-01-29 05:19:52 +00:00
|
|
|
if (overflow && !err) {
|
|
|
|
block += count;
|
|
|
|
count = overflow;
|
2023-09-28 16:04:01 +00:00
|
|
|
ext4_mb_unload_buddy(&e4b);
|
2022-07-14 16:59:03 +00:00
|
|
|
/* The range changed so it's no longer validated */
|
|
|
|
flags &= ~EXT4_FREE_BLOCKS_VALIDATED;
|
2008-01-29 05:19:52 +00:00
|
|
|
goto do_more;
|
|
|
|
}
|
2023-09-28 16:04:01 +00:00
|
|
|
|
|
|
|
error_clean:
|
|
|
|
ext4_mb_unload_buddy(&e4b);
|
|
|
|
error_out:
|
2008-01-29 05:19:52 +00:00
|
|
|
ext4_std_error(sb, err);
|
|
|
|
}
|
2010-10-28 01:30:12 +00:00
|
|
|
|
2022-02-16 07:02:45 +00:00
|
|
|
/**
|
|
|
|
* ext4_free_blocks() -- Free given blocks and update quota
|
|
|
|
* @handle: handle for this transaction
|
|
|
|
* @inode: inode
|
|
|
|
* @bh: optional buffer of the block to be freed
|
|
|
|
* @block: starting physical block to be freed
|
|
|
|
* @count: number of blocks to be freed
|
|
|
|
* @flags: flags used by ext4_free_blocks
|
|
|
|
*/
|
|
|
|
void ext4_free_blocks(handle_t *handle, struct inode *inode,
|
|
|
|
struct buffer_head *bh, ext4_fsblk_t block,
|
|
|
|
unsigned long count, int flags)
|
|
|
|
{
|
|
|
|
struct super_block *sb = inode->i_sb;
|
|
|
|
unsigned int overflow;
|
|
|
|
struct ext4_sb_info *sbi;
|
|
|
|
|
|
|
|
sbi = EXT4_SB(sb);
|
|
|
|
|
|
|
|
if (bh) {
|
|
|
|
if (block)
|
|
|
|
BUG_ON(block != bh->b_blocknr);
|
|
|
|
else
|
|
|
|
block = bh->b_blocknr;
|
|
|
|
}
|
|
|
|
|
2023-06-03 15:03:16 +00:00
|
|
|
if (sbi->s_mount_state & EXT4_FC_REPLAY) {
|
2023-06-03 15:03:19 +00:00
|
|
|
ext4_free_blocks_simple(inode, block, EXT4_NUM_B2C(sbi, count));
|
2023-06-03 15:03:16 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
might_sleep();
|
|
|
|
|
2022-02-16 07:02:45 +00:00
|
|
|
if (!(flags & EXT4_FREE_BLOCKS_VALIDATED) &&
|
|
|
|
!ext4_inode_block_valid(inode, block, count)) {
|
|
|
|
ext4_error(sb, "Freeing blocks not in datazone - "
|
|
|
|
"block = %llu, count = %lu", block, count);
|
|
|
|
return;
|
|
|
|
}
|
2022-07-14 16:59:03 +00:00
|
|
|
flags |= EXT4_FREE_BLOCKS_VALIDATED;
|
2022-02-16 07:02:45 +00:00
|
|
|
|
|
|
|
ext4_debug("freeing block %llu\n", block);
|
|
|
|
trace_ext4_free_blocks(inode, block, count, flags);
|
|
|
|
|
|
|
|
if (bh && (flags & EXT4_FREE_BLOCKS_FORGET)) {
|
|
|
|
BUG_ON(count > 1);
|
|
|
|
|
|
|
|
ext4_forget(handle, flags & EXT4_FREE_BLOCKS_METADATA,
|
|
|
|
inode, bh, block);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the extent to be freed does not begin on a cluster
|
|
|
|
* boundary, we need to deal with partial clusters at the
|
|
|
|
* beginning and end of the extent. Normally we will free
|
|
|
|
* blocks at the beginning or the end unless we are explicitly
|
|
|
|
* requested to avoid doing so.
|
|
|
|
*/
|
|
|
|
overflow = EXT4_PBLK_COFF(sbi, block);
|
|
|
|
if (overflow) {
|
|
|
|
if (flags & EXT4_FREE_BLOCKS_NOFREE_FIRST_CLUSTER) {
|
|
|
|
overflow = sbi->s_cluster_ratio - overflow;
|
|
|
|
block += overflow;
|
|
|
|
if (count > overflow)
|
|
|
|
count -= overflow;
|
|
|
|
else
|
|
|
|
return;
|
|
|
|
} else {
|
|
|
|
block -= overflow;
|
|
|
|
count += overflow;
|
|
|
|
}
|
2022-07-14 16:59:03 +00:00
|
|
|
/* The range changed so it's no longer validated */
|
|
|
|
flags &= ~EXT4_FREE_BLOCKS_VALIDATED;
|
2022-02-16 07:02:45 +00:00
|
|
|
}
|
|
|
|
overflow = EXT4_LBLK_COFF(sbi, count);
|
|
|
|
if (overflow) {
|
|
|
|
if (flags & EXT4_FREE_BLOCKS_NOFREE_LAST_CLUSTER) {
|
|
|
|
if (count > overflow)
|
|
|
|
count -= overflow;
|
|
|
|
else
|
|
|
|
return;
|
|
|
|
} else
|
|
|
|
count += sbi->s_cluster_ratio - overflow;
|
2022-07-14 16:59:03 +00:00
|
|
|
/* The range changed so it's no longer validated */
|
|
|
|
flags &= ~EXT4_FREE_BLOCKS_VALIDATED;
|
2022-02-16 07:02:45 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!bh && (flags & EXT4_FREE_BLOCKS_FORGET)) {
|
|
|
|
int i;
|
|
|
|
int is_metadata = flags & EXT4_FREE_BLOCKS_METADATA;
|
|
|
|
|
|
|
|
for (i = 0; i < count; i++) {
|
|
|
|
cond_resched();
|
|
|
|
if (is_metadata)
|
|
|
|
bh = sb_find_get_block(inode->i_sb, block + i);
|
|
|
|
ext4_forget(handle, is_metadata, inode, bh, block + i);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
ext4_mb_clear_bb(handle, inode, block, count, flags);
|
|
|
|
}
|
|
|
|
|
2011-05-09 14:46:41 +00:00
|
|
|
/**
|
2011-07-27 01:43:56 +00:00
|
|
|
* ext4_group_add_blocks() -- Add given blocks to an existing group
|
2011-05-09 14:46:41 +00:00
|
|
|
* @handle: handle to this transaction
|
|
|
|
* @sb: super block
|
2012-09-01 17:31:09 +00:00
|
|
|
* @block: start physical block to add to the block group
|
2011-05-09 14:46:41 +00:00
|
|
|
* @count: number of blocks to free
|
|
|
|
*
|
2011-05-10 01:40:01 +00:00
|
|
|
* This marks the blocks as free in the bitmap and buddy.
|
2011-05-09 14:46:41 +00:00
|
|
|
*/
|
2011-07-27 01:46:07 +00:00
|
|
|
int ext4_group_add_blocks(handle_t *handle, struct super_block *sb,
|
2011-05-09 14:46:41 +00:00
|
|
|
ext4_fsblk_t block, unsigned long count)
|
|
|
|
{
|
|
|
|
ext4_group_t block_group;
|
|
|
|
ext4_grpblk_t bit;
|
|
|
|
struct ext4_sb_info *sbi = EXT4_SB(sb);
|
2011-05-10 01:40:01 +00:00
|
|
|
struct ext4_buddy e4b;
|
2023-09-28 16:04:04 +00:00
|
|
|
int err = 0;
|
2017-10-29 13:38:46 +00:00
|
|
|
ext4_fsblk_t first_cluster = EXT4_B2C(sbi, block);
|
|
|
|
ext4_fsblk_t last_cluster = EXT4_B2C(sbi, block + count - 1);
|
|
|
|
unsigned long cluster_count = last_cluster - first_cluster + 1;
|
2023-09-28 16:04:04 +00:00
|
|
|
ext4_grpblk_t changed;
|
2011-05-09 14:46:41 +00:00
|
|
|
|
|
|
|
ext4_debug("Adding block(s) %llu-%llu\n", block, block + count - 1);
|
|
|
|
|
2023-09-28 16:04:04 +00:00
|
|
|
if (cluster_count == 0)
|
2011-07-27 01:51:08 +00:00
|
|
|
return 0;
|
|
|
|
|
2011-05-09 14:46:41 +00:00
|
|
|
ext4_get_group_no_and_offset(sb, block, &block_group, &bit);
|
|
|
|
/*
|
|
|
|
* Check to see if we are freeing blocks across a group
|
|
|
|
* boundary.
|
|
|
|
*/
|
2017-10-29 13:38:46 +00:00
|
|
|
if (bit + cluster_count > EXT4_CLUSTERS_PER_GROUP(sb)) {
|
|
|
|
ext4_warning(sb, "too many blocks added to group %u",
|
2011-07-27 01:46:07 +00:00
|
|
|
block_group);
|
|
|
|
err = -EINVAL;
|
2023-09-28 16:04:03 +00:00
|
|
|
goto error_out;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = ext4_mb_load_buddy(sb, block_group, &e4b);
|
|
|
|
if (err)
|
|
|
|
goto error_out;
|
|
|
|
|
|
|
|
if (!ext4_sb_block_valid(sb, NULL, block, count)) {
|
|
|
|
ext4_error(sb, "Adding blocks in system zones - "
|
|
|
|
"Block = %llu, count = %lu",
|
|
|
|
block, count);
|
|
|
|
err = -EINVAL;
|
|
|
|
goto error_clean;
|
2011-07-27 01:46:07 +00:00
|
|
|
}
|
2011-05-09 14:58:45 +00:00
|
|
|
|
2023-09-28 16:04:04 +00:00
|
|
|
err = ext4_mb_mark_context(handle, sb, false, block_group, bit,
|
|
|
|
cluster_count, EXT4_MB_BITMAP_MARKED_CHECK,
|
|
|
|
&changed);
|
|
|
|
if (err && changed == 0)
|
2023-09-28 16:04:03 +00:00
|
|
|
goto error_clean;
|
2011-05-10 01:40:01 +00:00
|
|
|
|
2023-09-28 16:04:04 +00:00
|
|
|
if (changed != cluster_count)
|
|
|
|
ext4_error(sb, "bit already cleared in group %u", block_group);
|
2011-05-09 14:46:41 +00:00
|
|
|
|
2023-09-28 16:04:03 +00:00
|
|
|
ext4_lock_group(sb, block_group);
|
|
|
|
mb_free_blocks(NULL, &e4b, bit, cluster_count);
|
|
|
|
ext4_unlock_group(sb, block_group);
|
|
|
|
percpu_counter_add(&sbi->s_freeclusters_counter,
|
2023-09-28 16:04:04 +00:00
|
|
|
changed);
|
2023-09-28 16:04:03 +00:00
|
|
|
|
|
|
|
error_clean:
|
|
|
|
ext4_mb_unload_buddy(&e4b);
|
|
|
|
error_out:
|
2011-05-09 14:46:41 +00:00
|
|
|
ext4_std_error(sb, err);
|
2011-07-27 01:46:07 +00:00
|
|
|
return err;
|
2011-05-09 14:46:41 +00:00
|
|
|
}
|
|
|
|
|
2010-10-28 01:30:12 +00:00
|
|
|
/**
|
|
|
|
* ext4_trim_extent -- function to TRIM one single free extent in the group
|
|
|
|
* @sb: super block for the file system
|
|
|
|
* @start: starting block of the free extent in the alloc. group
|
|
|
|
* @count: number of blocks to TRIM
|
|
|
|
* @e4b: ext4 buddy for the group
|
|
|
|
*
|
|
|
|
* Trim "count" blocks starting at "start" in the "group". To assure that no
|
|
|
|
* one will allocate those blocks, mark it as used in buddy bitmap. This must
|
|
|
|
* be called with under the group lock.
|
|
|
|
*/
|
2021-07-24 07:41:20 +00:00
|
|
|
static int ext4_trim_extent(struct super_block *sb,
|
|
|
|
int start, int count, struct ext4_buddy *e4b)
|
2014-04-13 03:01:28 +00:00
|
|
|
__releases(bitlock)
|
|
|
|
__acquires(bitlock)
|
2010-10-28 01:30:12 +00:00
|
|
|
{
|
|
|
|
struct ext4_free_extent ex;
|
2021-07-24 07:41:20 +00:00
|
|
|
ext4_group_t group = e4b->bd_group;
|
2012-11-08 19:04:52 +00:00
|
|
|
int ret = 0;
|
2010-10-28 01:30:12 +00:00
|
|
|
|
2011-07-11 04:01:52 +00:00
|
|
|
trace_ext4_trim_extent(sb, group, start, count);
|
|
|
|
|
2010-10-28 01:30:12 +00:00
|
|
|
assert_spin_locked(ext4_group_lock_ptr(sb, group));
|
|
|
|
|
|
|
|
ex.fe_start = start;
|
|
|
|
ex.fe_group = group;
|
|
|
|
ex.fe_len = count;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Mark blocks used, so no one can reuse them while
|
|
|
|
* being trimmed.
|
|
|
|
*/
|
|
|
|
mb_mark_used(e4b, &ex);
|
|
|
|
ext4_unlock_group(sb, group);
|
2024-02-26 08:17:31 +00:00
|
|
|
ret = ext4_issue_discard(sb, group, start, count);
|
2010-10-28 01:30:12 +00:00
|
|
|
ext4_lock_group(sb, group);
|
|
|
|
mb_free_blocks(NULL, e4b, start, ex.fe_len);
|
2012-11-08 19:04:52 +00:00
|
|
|
return ret;
|
2010-10-28 01:30:12 +00:00
|
|
|
}
|
|
|
|
|
2023-09-13 15:04:54 +00:00
|
|
|
static ext4_grpblk_t ext4_last_grp_cluster(struct super_block *sb,
|
|
|
|
ext4_group_t grp)
|
|
|
|
{
|
2023-12-13 05:16:35 +00:00
|
|
|
unsigned long nr_clusters_in_group;
|
|
|
|
|
|
|
|
if (grp < (ext4_get_groups_count(sb) - 1))
|
|
|
|
nr_clusters_in_group = EXT4_CLUSTERS_PER_GROUP(sb);
|
|
|
|
else
|
|
|
|
nr_clusters_in_group = (ext4_blocks_count(EXT4_SB(sb)->s_es) -
|
|
|
|
ext4_group_first_block_no(sb, grp))
|
|
|
|
>> EXT4_CLUSTER_BITS(sb);
|
|
|
|
|
|
|
|
return nr_clusters_in_group - 1;
|
2023-09-13 15:04:54 +00:00
|
|
|
}
|
|
|
|
|
2023-09-13 15:04:55 +00:00
|
|
|
static bool ext4_trim_interrupted(void)
|
|
|
|
{
|
|
|
|
return fatal_signal_pending(current) || freezing(current);
|
|
|
|
}
|
|
|
|
|
2021-07-24 07:41:21 +00:00
|
|
|
static int ext4_try_to_trim_range(struct super_block *sb,
|
|
|
|
struct ext4_buddy *e4b, ext4_grpblk_t start,
|
|
|
|
ext4_grpblk_t max, ext4_grpblk_t minblocks)
|
2021-08-14 14:41:30 +00:00
|
|
|
__acquires(ext4_group_lock_ptr(sb, e4b->bd_group))
|
|
|
|
__releases(ext4_group_lock_ptr(sb, e4b->bd_group))
|
2021-07-24 07:41:21 +00:00
|
|
|
{
|
2023-12-16 01:09:19 +00:00
|
|
|
ext4_grpblk_t next, count, free_count, last, origin_start;
|
2023-09-13 15:04:54 +00:00
|
|
|
bool set_trimmed = false;
|
2021-07-24 07:41:21 +00:00
|
|
|
void *bitmap;
|
|
|
|
|
2024-01-04 14:20:34 +00:00
|
|
|
if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)))
|
|
|
|
return 0;
|
|
|
|
|
2023-12-16 01:09:19 +00:00
|
|
|
last = ext4_last_grp_cluster(sb, e4b->bd_group);
|
2021-07-24 07:41:21 +00:00
|
|
|
bitmap = e4b->bd_bitmap;
|
2023-12-16 01:09:19 +00:00
|
|
|
if (start == 0 && max >= last)
|
2023-09-13 15:04:54 +00:00
|
|
|
set_trimmed = true;
|
2023-12-16 01:09:19 +00:00
|
|
|
origin_start = start;
|
2023-08-01 14:32:00 +00:00
|
|
|
start = max(e4b->bd_info->bb_first_free, start);
|
2021-07-24 07:41:21 +00:00
|
|
|
count = 0;
|
|
|
|
free_count = 0;
|
|
|
|
|
|
|
|
while (start <= max) {
|
|
|
|
start = mb_find_next_zero_bit(bitmap, max + 1, start);
|
|
|
|
if (start > max)
|
|
|
|
break;
|
2023-12-16 01:09:19 +00:00
|
|
|
|
|
|
|
next = mb_find_next_bit(bitmap, last + 1, start);
|
|
|
|
if (origin_start == 0 && next >= last)
|
|
|
|
set_trimmed = true;
|
2021-07-24 07:41:21 +00:00
|
|
|
|
|
|
|
if ((next - start) >= minblocks) {
|
2021-08-20 12:08:53 +00:00
|
|
|
int ret = ext4_trim_extent(sb, start, next - start, e4b);
|
|
|
|
|
2021-07-24 07:41:21 +00:00
|
|
|
if (ret && ret != -EOPNOTSUPP)
|
2023-09-13 15:04:54 +00:00
|
|
|
return count;
|
2021-07-24 07:41:21 +00:00
|
|
|
count += next - start;
|
|
|
|
}
|
|
|
|
free_count += next - start;
|
|
|
|
start = next + 1;
|
|
|
|
|
2023-09-13 15:04:55 +00:00
|
|
|
if (ext4_trim_interrupted())
|
|
|
|
return count;
|
2021-07-24 07:41:21 +00:00
|
|
|
|
|
|
|
if (need_resched()) {
|
|
|
|
ext4_unlock_group(sb, e4b->bd_group);
|
|
|
|
cond_resched();
|
|
|
|
ext4_lock_group(sb, e4b->bd_group);
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((e4b->bd_info->bb_free - free_count) < minblocks)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2023-09-13 15:04:54 +00:00
|
|
|
if (set_trimmed)
|
|
|
|
EXT4_MB_GRP_SET_TRIMMED(e4b->bd_info);
|
|
|
|
|
2021-07-24 07:41:21 +00:00
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
2010-10-28 01:30:12 +00:00
|
|
|
/**
|
|
|
|
* ext4_trim_all_free -- function to trim all free space in alloc. group
|
|
|
|
* @sb: super block for file system
|
2011-07-11 04:04:34 +00:00
|
|
|
* @group: group to be trimmed
|
2010-10-28 01:30:12 +00:00
|
|
|
* @start: first group block to examine
|
|
|
|
* @max: last group block to examine
|
|
|
|
* @minblocks: minimum extent block count
|
|
|
|
*
|
|
|
|
* ext4_trim_all_free walks through group's block bitmap searching for free
|
|
|
|
* extents. When the free extent is found, mark it as used in group buddy
|
|
|
|
* bitmap. Then issue a TRIM command on this extent and free the extent in
|
2021-07-24 07:41:22 +00:00
|
|
|
* the group buddy bitmap.
|
2010-10-28 01:30:12 +00:00
|
|
|
*/
|
2011-02-23 17:22:49 +00:00
|
|
|
static ext4_grpblk_t
|
2011-05-24 22:16:27 +00:00
|
|
|
ext4_trim_all_free(struct super_block *sb, ext4_group_t group,
|
|
|
|
ext4_grpblk_t start, ext4_grpblk_t max,
|
2023-09-13 15:04:54 +00:00
|
|
|
ext4_grpblk_t minblocks)
|
2010-10-28 01:30:12 +00:00
|
|
|
{
|
2011-05-24 22:16:27 +00:00
|
|
|
struct ext4_buddy e4b;
|
2021-07-24 07:41:21 +00:00
|
|
|
int ret;
|
2010-10-28 01:30:12 +00:00
|
|
|
|
2011-07-11 04:01:52 +00:00
|
|
|
trace_ext4_trim_all_free(sb, group, start, max);
|
|
|
|
|
2011-05-24 22:16:27 +00:00
|
|
|
ret = ext4_mb_load_buddy(sb, group, &e4b);
|
|
|
|
if (ret) {
|
2017-05-22 02:35:23 +00:00
|
|
|
ext4_warning(sb, "Error %d loading buddy information for %u",
|
|
|
|
ret, group);
|
2011-05-24 22:16:27 +00:00
|
|
|
return ret;
|
|
|
|
}
|
2011-05-24 22:28:07 +00:00
|
|
|
|
|
|
|
ext4_lock_group(sb, group);
|
2010-10-28 01:30:12 +00:00
|
|
|
|
2021-07-24 07:41:21 +00:00
|
|
|
if (!EXT4_MB_GRP_WAS_TRIMMED(e4b.bd_info) ||
|
2023-09-13 15:04:54 +00:00
|
|
|
minblocks < EXT4_SB(sb)->s_last_trim_minblks)
|
2021-07-24 07:41:21 +00:00
|
|
|
ret = ext4_try_to_trim_range(sb, &e4b, start, max, minblocks);
|
2023-09-13 15:04:54 +00:00
|
|
|
else
|
2021-07-24 07:41:21 +00:00
|
|
|
ret = 0;
|
2011-07-11 04:03:38 +00:00
|
|
|
|
2010-10-28 01:30:12 +00:00
|
|
|
ext4_unlock_group(sb, group);
|
2011-05-24 22:16:27 +00:00
|
|
|
ext4_mb_unload_buddy(&e4b);
|
2010-10-28 01:30:12 +00:00
|
|
|
|
|
|
|
ext4_debug("trimmed %d blocks in the group %d\n",
|
2021-07-24 07:41:21 +00:00
|
|
|
ret, group);
|
2010-10-28 01:30:12 +00:00
|
|
|
|
2012-11-08 19:04:52 +00:00
|
|
|
return ret;
|
2010-10-28 01:30:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ext4_trim_fs() -- trim ioctl handle function
|
|
|
|
* @sb: superblock for filesystem
|
|
|
|
* @range: fstrim_range structure
|
|
|
|
*
|
|
|
|
* start: First Byte to trim
|
|
|
|
* len: number of Bytes to trim from start
|
|
|
|
* minlen: minimum extent length in Bytes
|
|
|
|
* ext4_trim_fs goes through all allocation groups containing Bytes from
|
|
|
|
* start to start+len. For each such a group ext4_trim_all_free function
|
|
|
|
* is invoked to trim all free space.
|
|
|
|
*/
|
|
|
|
int ext4_trim_fs(struct super_block *sb, struct fstrim_range *range)
|
|
|
|
{
|
2022-04-15 04:52:56 +00:00
|
|
|
unsigned int discard_granularity = bdev_discard_granularity(sb->s_bdev);
|
2011-05-24 22:16:27 +00:00
|
|
|
struct ext4_group_info *grp;
|
2012-03-22 01:22:22 +00:00
|
|
|
ext4_group_t group, first_group, last_group;
|
2011-09-09 22:38:51 +00:00
|
|
|
ext4_grpblk_t cnt = 0, first_cluster, last_cluster;
|
2012-03-22 01:22:22 +00:00
|
|
|
uint64_t start, end, minlen, trimmed = 0;
|
2011-01-11 20:16:31 +00:00
|
|
|
ext4_fsblk_t first_data_blk =
|
|
|
|
le32_to_cpu(EXT4_SB(sb)->s_es->s_first_data_block);
|
2012-03-22 01:22:22 +00:00
|
|
|
ext4_fsblk_t max_blks = ext4_blocks_count(EXT4_SB(sb)->s_es);
|
2010-10-28 01:30:12 +00:00
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
start = range->start >> sb->s_blocksize_bits;
|
2012-03-22 01:22:22 +00:00
|
|
|
end = start + (range->len >> sb->s_blocksize_bits) - 1;
|
2012-09-27 02:21:21 +00:00
|
|
|
minlen = EXT4_NUM_B2C(EXT4_SB(sb),
|
|
|
|
range->minlen >> sb->s_blocksize_bits);
|
2010-10-28 01:30:12 +00:00
|
|
|
|
2012-10-22 22:01:19 +00:00
|
|
|
if (minlen > EXT4_CLUSTERS_PER_GROUP(sb) ||
|
|
|
|
start >= max_blks ||
|
|
|
|
range->len < sb->s_blocksize)
|
2010-10-28 01:30:12 +00:00
|
|
|
return -EINVAL;
|
2021-11-12 15:22:02 +00:00
|
|
|
/* No point to try to trim less than discard granularity */
|
2022-04-15 04:52:56 +00:00
|
|
|
if (range->minlen < discard_granularity) {
|
2021-11-12 15:22:02 +00:00
|
|
|
minlen = EXT4_NUM_B2C(EXT4_SB(sb),
|
2022-04-15 04:52:56 +00:00
|
|
|
discard_granularity >> sb->s_blocksize_bits);
|
2021-11-12 15:22:02 +00:00
|
|
|
if (minlen > EXT4_CLUSTERS_PER_GROUP(sb))
|
|
|
|
goto out;
|
|
|
|
}
|
2023-09-13 15:04:54 +00:00
|
|
|
if (end >= max_blks - 1)
|
2012-03-22 01:22:22 +00:00
|
|
|
end = max_blks - 1;
|
|
|
|
if (end <= first_data_blk)
|
2011-07-11 03:52:37 +00:00
|
|
|
goto out;
|
2012-03-22 01:22:22 +00:00
|
|
|
if (start < first_data_blk)
|
2011-01-11 20:16:31 +00:00
|
|
|
start = first_data_blk;
|
2010-10-28 01:30:12 +00:00
|
|
|
|
2012-03-22 01:22:22 +00:00
|
|
|
/* Determine first and last group to examine based on start and end */
|
2010-10-28 01:30:12 +00:00
|
|
|
ext4_get_group_no_and_offset(sb, (ext4_fsblk_t) start,
|
2011-09-09 22:38:51 +00:00
|
|
|
&first_group, &first_cluster);
|
2012-03-22 01:22:22 +00:00
|
|
|
ext4_get_group_no_and_offset(sb, (ext4_fsblk_t) end,
|
2011-09-09 22:38:51 +00:00
|
|
|
&last_group, &last_cluster);
|
2010-10-28 01:30:12 +00:00
|
|
|
|
2012-03-22 01:22:22 +00:00
|
|
|
/* end now represents the last cluster to discard in this group */
|
|
|
|
end = EXT4_CLUSTERS_PER_GROUP(sb) - 1;
|
2010-10-28 01:30:12 +00:00
|
|
|
|
|
|
|
for (group = first_group; group <= last_group; group++) {
|
2023-09-13 15:04:55 +00:00
|
|
|
if (ext4_trim_interrupted())
|
|
|
|
break;
|
2011-05-24 22:16:27 +00:00
|
|
|
grp = ext4_get_group_info(sb, group);
|
ext4: allow ext4_get_group_info() to fail
Previously, ext4_get_group_info() would treat an invalid group number
as BUG(), since in theory it should never happen. However, if a
malicious attaker (or fuzzer) modifies the superblock via the block
device while it is the file system is mounted, it is possible for
s_first_data_block to get set to a very large number. In that case,
when calculating the block group of some block number (such as the
starting block of a preallocation region), could result in an
underflow and very large block group number. Then the BUG_ON check in
ext4_get_group_info() would fire, resutling in a denial of service
attack that can be triggered by root or someone with write access to
the block device.
For a quality of implementation perspective, it's best that even if
the system administrator does something that they shouldn't, that it
will not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()
will call ext4_error and return NULL. We also add fallback code in
all of the callers of ext4_get_group_info() that it might NULL.
Also, since ext4_get_group_info() was already borderline to be an
inline function, un-inline it. The results in a next reduction of the
compiled text size of ext4 by roughly 2k.
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20230430154311.579720-2-tytso@mit.edu
Reported-by: syzbot+e2efa3efc15a1c9e95c3@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=69b28112e098b070f639efb356393af3ffec4220
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
2023-04-29 04:06:28 +00:00
|
|
|
if (!grp)
|
|
|
|
continue;
|
2011-05-24 22:16:27 +00:00
|
|
|
/* We only do this if the grp has never been initialized */
|
|
|
|
if (unlikely(EXT4_MB_GRP_NEED_INIT(grp))) {
|
2016-03-13 21:29:06 +00:00
|
|
|
ret = ext4_mb_init_group(sb, group, GFP_NOFS);
|
2011-05-24 22:16:27 +00:00
|
|
|
if (ret)
|
|
|
|
break;
|
2010-10-28 01:30:12 +00:00
|
|
|
}
|
|
|
|
|
2011-03-23 19:48:11 +00:00
|
|
|
/*
|
2012-03-22 01:22:22 +00:00
|
|
|
* For all the groups except the last one, last cluster will
|
|
|
|
* always be EXT4_CLUSTERS_PER_GROUP(sb)-1, so we only need to
|
|
|
|
* change it for the last group, note that last_cluster is
|
|
|
|
* already computed earlier by ext4_get_group_no_and_offset()
|
2011-03-23 19:48:11 +00:00
|
|
|
*/
|
2023-09-13 15:04:54 +00:00
|
|
|
if (group == last_group)
|
2012-03-22 01:22:22 +00:00
|
|
|
end = last_cluster;
|
2011-05-24 22:16:27 +00:00
|
|
|
if (grp->bb_free >= minlen) {
|
2011-09-09 22:38:51 +00:00
|
|
|
cnt = ext4_trim_all_free(sb, group, first_cluster,
|
2023-09-13 15:04:54 +00:00
|
|
|
end, minlen);
|
2010-10-28 01:30:12 +00:00
|
|
|
if (cnt < 0) {
|
|
|
|
ret = cnt;
|
|
|
|
break;
|
|
|
|
}
|
2012-03-22 01:24:22 +00:00
|
|
|
trimmed += cnt;
|
2010-10-28 01:30:12 +00:00
|
|
|
}
|
2012-03-22 01:22:22 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* For every group except the first one, we are sure
|
|
|
|
* that the first cluster to discard will be cluster #0.
|
|
|
|
*/
|
2011-09-09 22:38:51 +00:00
|
|
|
first_cluster = 0;
|
2010-10-28 01:30:12 +00:00
|
|
|
}
|
|
|
|
|
2011-07-11 04:03:38 +00:00
|
|
|
if (!ret)
|
2021-11-03 14:51:21 +00:00
|
|
|
EXT4_SB(sb)->s_last_trim_minblks = minlen;
|
2011-07-11 04:03:38 +00:00
|
|
|
|
2011-07-11 03:52:37 +00:00
|
|
|
out:
|
2012-09-27 02:21:21 +00:00
|
|
|
range->len = EXT4_C2B(EXT4_SB(sb), trimmed) << sb->s_blocksize_bits;
|
2010-10-28 01:30:12 +00:00
|
|
|
return ret;
|
|
|
|
}
|
2017-04-30 04:36:53 +00:00
|
|
|
|
|
|
|
/* Iterate all the free extents in the group. */
|
|
|
|
int
|
|
|
|
ext4_mballoc_query_range(
|
|
|
|
struct super_block *sb,
|
|
|
|
ext4_group_t group,
|
2024-10-23 04:25:37 +00:00
|
|
|
ext4_grpblk_t first,
|
2017-04-30 04:36:53 +00:00
|
|
|
ext4_grpblk_t end,
|
2024-10-23 04:25:37 +00:00
|
|
|
ext4_mballoc_query_range_fn meta_formatter,
|
2017-04-30 04:36:53 +00:00
|
|
|
ext4_mballoc_query_range_fn formatter,
|
|
|
|
void *priv)
|
|
|
|
{
|
|
|
|
void *bitmap;
|
2024-10-23 04:25:37 +00:00
|
|
|
ext4_grpblk_t start, next;
|
2017-04-30 04:36:53 +00:00
|
|
|
struct ext4_buddy e4b;
|
|
|
|
int error;
|
|
|
|
|
|
|
|
error = ext4_mb_load_buddy(sb, group, &e4b);
|
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
bitmap = e4b.bd_bitmap;
|
|
|
|
|
|
|
|
ext4_lock_group(sb, group);
|
|
|
|
|
2024-10-23 04:25:37 +00:00
|
|
|
start = max(e4b.bd_info->bb_first_free, first);
|
2017-04-30 04:36:53 +00:00
|
|
|
if (end >= EXT4_CLUSTERS_PER_GROUP(sb))
|
|
|
|
end = EXT4_CLUSTERS_PER_GROUP(sb) - 1;
|
2024-10-23 04:25:37 +00:00
|
|
|
if (meta_formatter && start != first) {
|
|
|
|
if (start > end)
|
|
|
|
start = end;
|
|
|
|
ext4_unlock_group(sb, group);
|
|
|
|
error = meta_formatter(sb, group, first, start - first,
|
|
|
|
priv);
|
|
|
|
if (error)
|
|
|
|
goto out_unload;
|
|
|
|
ext4_lock_group(sb, group);
|
|
|
|
}
|
2017-04-30 04:36:53 +00:00
|
|
|
while (start <= end) {
|
|
|
|
start = mb_find_next_zero_bit(bitmap, end + 1, start);
|
|
|
|
if (start > end)
|
|
|
|
break;
|
|
|
|
next = mb_find_next_bit(bitmap, end + 1, start);
|
|
|
|
|
|
|
|
ext4_unlock_group(sb, group);
|
|
|
|
error = formatter(sb, group, start, next - start, priv);
|
|
|
|
if (error)
|
|
|
|
goto out_unload;
|
|
|
|
ext4_lock_group(sb, group);
|
|
|
|
|
|
|
|
start = next + 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
ext4_unlock_group(sb, group);
|
|
|
|
out_unload:
|
|
|
|
ext4_mb_unload_buddy(&e4b);
|
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
2023-09-28 16:04:06 +00:00
|
|
|
|
|
|
|
#ifdef CONFIG_EXT4_KUNIT_TESTS
|
|
|
|
#include "mballoc-test.c"
|
|
|
|
#endif
|