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

Sweet Tea Dorminy posted 2 patches 4 years, 2 months ago
There is a newer version of this series
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(-)
[PATCH v2 0/2] btrfs: allocate page arrays more efficiently
Posted by Sweet Tea Dorminy 4 years, 2 months ago
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(-)

-- 
2.35.1
Re: [PATCH v2 0/2] btrfs: allocate page arrays more efficiently
Posted by David Sterba 4 years, 2 months ago
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
Re: [PATCH v2 0/2] btrfs: allocate page arrays more efficiently
Posted by Sweet Tea Dorminy 4 years, 2 months ago

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.
Re: [PATCH v2 0/2] btrfs: allocate page arrays more efficiently
Posted by David Sterba 4 years, 2 months ago
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.