In several places, btrfs allocates an array of pages, one at a time. In
addition to duplicating code, the mm subsystem provides a helper to
allocate multiple pages at once into an array which is suited for our
usecase. In the fast path, the batching can result in better allocation
decisions and less locking. This changeset first adjusts the users to
call a common array-of-pages allocation function, then adjusts that
common function to use the batch page allocator.
Sweet Tea Dorminy (2):
btrfs: Factor out allocating an array of pages.
btrfs: Allocate page arrays using bulk page allocator.
fs/btrfs/check-integrity.c | 8 +++-----
fs/btrfs/compression.c | 37 +++++++++++++++--------------------
fs/btrfs/ctree.c | 32 ++++++++++++++++++++++++++++++
fs/btrfs/ctree.h | 2 ++
fs/btrfs/extent_io.c | 40 +++++++++++++++++++++++---------------
fs/btrfs/inode.c | 10 ++++------
fs/btrfs/raid56.c | 30 ++++------------------------
7 files changed, 85 insertions(+), 74 deletions(-)
--
2.35.1
On Mon, Mar 28, 2022 at 04:14:26PM -0400, Sweet Tea Dorminy wrote:
> In several places, btrfs allocates an array of pages, one at a time. In
> addition to duplicating code, the mm subsystem provides a helper to
> allocate multiple pages at once into an array which is suited for our
> usecase. In the fast path, the batching can result in better allocation
> decisions and less locking. This changeset first adjusts the users to
> call a common array-of-pages allocation function, then adjusts that
> common function to use the batch page allocator.
Makes sense, the allocator internal knowledge can improve things. Though
after some time the memory often is fragmented and the bulk allocator
could fall back to single page allocation, it won't be worse than what
we already have.
I have some coding style comments, will reply under the patches,
otherwise the series looks good.