Re: [PATCH 0/3] btrfs: use kvmalloc() for allocations that can be larger than page size

[David Sterba <dsterba@suse.cz>]

On Tue, Sep 08, 2026 at 04:45:38PM +0930, Qu Wenruo wrote:
> With the experimental bs > ps support, btrfs can hit several kmalloc()
> call sites requesting physically contiguous memory that are larger
> than a page, sometimes such allocation can be as large as 64K.
> 
> This means those kmalloc() has a much higher chance to fail if the
> system's available memory is very fragmented on 4K page sized systems.
> 
> And there is already a report that with 64K nodesize, even bs == ps we
> can still hit such kmalloc() failure.
> (https://lore.kernel.org/linux-btrfs/250decb0-d940-4fe6-9b54-d06e1b293a1b@suse.com/)
> 
> But we do not really require any physically contiguous memory for a lot
> of kmalloc() call sites, we just want a buffer to save some data
> temporarily.
> 
> So change those possible larger than page size kmalloc() to kvmalloc()
> to reduce the chance of memory allocation failure.
> 
> And since kvmalloc() falls back to kmalloc() if the allocation is not
> larger than a page, it means for most cases it's still calling
> kmalloc(), not affecting the most common cases anyway.

I've asked around, confirming that virtual mappings and allocations are
not a problem on 64bit systems so we can do the kvmalloc as needed.

> The first patch is a special case that affects the existing bs == ps
> cases already.
> The second one only affects bs > ps cases.
> The third one mostly affects bs > ps cases, but can still improve S390's
> hardware accelerated path with 4K page size.

If it's for hardware acceleration the memory can be DMAd then virtual
memory may not work. I haven't found any constraints for the s390
compression, it's a CPU instruction. It's quite possible assume there
are no limitation or the wrapper code falls back to software
compression.