mbox series

[v2,0/2] btrfs: allocate page arrays more efficiently

Message ID cover.1648658235.git.sweettea-kernel@dorminy.me (mailing list archive)
Headers show
Series btrfs: allocate page arrays more efficiently | expand

Message

Sweet Tea Dorminy March 30, 2022, 4:44 p.m. UTC
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.

v2: moved new helper to extent_io.[ch]. Fixed title format.
v1: https://lore.kernel.org/linux-btrfs/cover.1648496453.git.sweettea-kernel@dorminy.me/

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/extent_io.c       | 72 +++++++++++++++++++++++++++++---------
 fs/btrfs/extent_io.h       |  2 ++
 fs/btrfs/inode.c           | 10 +++---
 fs/btrfs/raid56.c          | 30 +++-------------
 6 files changed, 85 insertions(+), 74 deletions(-)

Comments

David Sterba March 30, 2022, 4:58 p.m. UTC | #1
On Wed, Mar 30, 2022 at 12:44:05PM -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.
> 
> v2: moved new helper to extent_io.[ch]. Fixed title format.

It does not address comments from
https://lore.kernel.org/linux-btrfs/20220328230909.GW2237@twin.jikos.cz
Sweet Tea Dorminy March 30, 2022, 6:08 p.m. UTC | #2
On 3/30/22 12:58, David Sterba wrote:
> On Wed, Mar 30, 2022 at 12:44:05PM -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.
>>
>> v2: moved new helper to extent_io.[ch]. Fixed title format.
> 
> It does not address comments from
> https://lore.kernel.org/linux-btrfs/20220328230909.GW2237@twin.jikos.cz
I apologize, I completely missed the inline comments even though I 
thought something was missing and reread it a couple times... v3 soon.
David Sterba March 31, 2022, 4:43 p.m. UTC | #3
On Wed, Mar 30, 2022 at 02:08:11PM -0400, Sweet Tea Dorminy wrote:
> 
> 
> On 3/30/22 12:58, David Sterba wrote:
> > On Wed, Mar 30, 2022 at 12:44:05PM -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.
> >>
> >> v2: moved new helper to extent_io.[ch]. Fixed title format.
> > 
> > It does not address comments from
> > https://lore.kernel.org/linux-btrfs/20220328230909.GW2237@twin.jikos.cz
> I apologize, I completely missed the inline comments even though I 
> thought something was missing and reread it a couple times... v3 soon.

Yeah it's common to not trim a patch and write comments right next to
the code, trimming to just a piece of code is also done if it's just the
one thing to comment, but for example I go through the patch several
times so trimming would not work very well.

If you're using mutt, there's a command (bound to T by default) that
hides any quoted text.