linux-kernel - Re: [RESEND v8 1/2] mm: store zero pages to be swapped out in a bitmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f4b5fefb-d5cb-4b21-845f-1c5a2165990d@gmail.com>
Date: Sat, 24 Aug 2024 14:58:47 -0400
From: Usama Arif <usamaarif642@...il.com>
To: Christophe JAILLET <christophe.jaillet@...adoo.fr>,
 akpm@...ux-foundation.org
Cc: hannes@...xchg.org, shakeel.butt@...ux.dev, david@...hat.com,
 ying.huang@...el.com, hughd@...gle.com, willy@...radead.org,
 yosryahmed@...gle.com, nphamcs@...il.com, chengming.zhou@...ux.dev,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org, kernel-team@...a.com,
 Andi Kleen <ak@...ux.intel.com>
Subject: Re: [RESEND v8 1/2] mm: store zero pages to be swapped out in a
 bitmap



On 24/08/2024 02:55, Christophe JAILLET wrote:
> Le 23/08/2024 à 21:04, Usama Arif a écrit :
>> Approximately 10-20% of pages to be swapped out are zero pages [1].
>> Rather than reading/writing these pages to flash resulting
>> in increased I/O and flash wear, a bitmap can be used to mark these
>> pages as zero at write time, and the pages can be filled at
>> read time if the bit corresponding to the page is set.
>> With this patch, NVMe writes in Meta server fleet decreased
>> by almost 10% with conventional swap setup (zswap disabled).
>>
>> [1] https://lore.kernel.org/all/20171018104832epcms5p1b2232e2236258de3d03d1344dde9fce0@epcms5p1/
>>
> 
> ...
> 
>> @@ -3428,6 +3444,17 @@ SYSCALL_DEFINE2(swapon, const char __user *, specialfile, int, swap_flags)
>>           goto bad_swap_unlock_inode;
>>       }
>>   +    /*
>> +     * Use kvmalloc_array instead of bitmap_zalloc as the allocation order might
>> +     * be above MAX_PAGE_ORDER incase of a large swap file.
>> +     */
>> +    zeromap = kvmalloc_array(BITS_TO_LONGS(maxpages), sizeof(long),
>> +                    GFP_KERNEL | __GFP_ZERO);
> 
> Nitpick: kvcalloc() maybe, to be slightly less verbose?
> 

There was quite a long discussion [1] on this in v5 of the series, and we settled no kvmalloc_array in the end. I think best to leave it as it is at kvmalloc_array.

Thanks

[1] https://lore.kernel.org/all/159061bc-27b5-4127-a85d-223bed0ddfd5@gmail.com/