Re: [PATCH 0/6] Remove highmem allocations, kmap/kunmap

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2021/7/8 下午8:45, Neal Gompa wrote:
> On Thu, Jul 8, 2021 at 7:48 AM David Sterba <dsterba@suse.com> wrote:
>>
>> The highmem was maybe was a good idea long time ago but with 64bit
>> architectures everywhere I don't think we need to take it into account.
>> This does not mean this 32bit won't work, just that it won't try to use
>> temporary pages in highmem for compression and raid56. The key word is
>> temporary. Combining a very fast device (like hundreds of megabytes
>> throughput) and 32bit machine with reasonable memory (for 32bit, like
>> 8G), it could become a problem once low memory is scarce.
>>
>> David Sterba (6):
>>    btrfs: drop from __GFP_HIGHMEM all allocations
>>    btrfs: compression: drop kmap/kunmap from lzo
>>    btrfs: compression: drop kmap/kunmap from zlib
>>    btrfs: compression: drop kmap/kunmap from zstd
>>    btrfs: compression: drop kmap/kunmap from generic helpers
>>    btrfs: check-integrity: drop kmap/kunmap for block pages
>>
>>   fs/btrfs/check-integrity.c | 11 +++-------
>>   fs/btrfs/compression.c     |  6 ++----
>>   fs/btrfs/inode.c           |  3 +--
>>   fs/btrfs/lzo.c             | 42 +++++++++++---------------------------
>>   fs/btrfs/raid56.c          | 10 ++++-----
>>   fs/btrfs/zlib.c            | 42 +++++++++++++-------------------------
>>   fs/btrfs/zstd.c            | 33 +++++++++++-------------------
>>   7 files changed, 49 insertions(+), 98 deletions(-)
>>
>
> I'd be concerned about the impact of this on SBC devices. All Fedora
> ARM images have zstd compression applied to them, and it would suck if
> we had a performance regression here because of this.

Sorry, I can't see the reason why it would cause performance drop or
higher memory usage.

The point of HIGHMEM is to work on archs where system can only access
memory below 4G reliably, any memory above 4G must be manually mapped
into the 4G range before access.

AFAIK it's only x86 using PAE needs this, and none of the ARM SoC uses
such feature.

So it shouldn't affect those ARM boards at all.

Thanks,
Qu