linux-kernel - Re: [RFC PATCH] mm/page_reporting: Adjust threshold according to MAX

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <c1aba468-d309-2fe7-74c3-1f93860482d8@redhat.com>
Date:   Fri, 11 Jun 2021 12:54:51 +1000
From:   Gavin Shan <gshan@...hat.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        alexander.h.duyck@...ux.intel.com, david@...hat.com,
        shan.gavin@...il.com
Subject: Re: [RFC PATCH] mm/page_reporting: Adjust threshold according to
 MAX_ORDER

On 6/2/21 10:03 AM, Andrew Morton wrote:
> On Tue,  1 Jun 2021 11:33:19 +0800 Gavin Shan <gshan@...hat.com> wrote:
> 
>> The PAGE_REPORTING_MIN_ORDER is equal to @pageblock_order, taken as
>> minimal order (threshold) to trigger page reporting. The page reporting
>> is never triggered with the following configurations and settings on
>> aarch64. In the particular scenario, the page reporting won't be triggered
>> until the largest (2 ^ (MAX_ORDER-1)) free area is achieved from the
>> page freeing. The condition is very hard, or even impossible to be met.
>>
>>    CONFIG_ARM64_PAGE_SHIFT:              16
>>    CONFIG_HUGETLB_PAGE:                  Y
>>    CONFIG_HUGETLB_PAGE_SIZE_VARIABLE:    N
>>    pageblock_order:                      13
>>    CONFIG_FORCE_MAX_ZONEORDER:           14
>>    MAX_ORDER:                            14
>>
>> The issue can be reproduced in VM, running kernel with above configurations
>> and settings. The 'memhog' is used inside the VM to access 512MB anonymous
>> area. The QEMU's RSS doesn't drop accordingly after 'memhog' exits.
>>
>>    /home/gavin/sandbox/qemu.main/build/qemu-system-aarch64          \
>>    -accel kvm -machine virt,gic-version=host                        \
>>    -cpu host -smp 8,sockets=2,cores=4,threads=1 -m 4096M,maxmem=64G \
>>    -object memory-backend-ram,id=mem0,size=2048M                    \
>>    -object memory-backend-ram,id=mem1,size=2048M                    \
>>    -numa node,nodeid=0,cpus=0-3,memdev=mem0                         \
>>    -numa node,nodeid=1,cpus=4-7,memdev=mem1                         \
>>      :                                                              \
>>    -device virtio-balloon-pci,id=balloon0,free-page-reporting=yes
>>
>> This tries to fix the issue by adjusting the threshold to the smaller value
>> of @pageblock_order and (MAX_ORDER/2). With this applied, the QEMU's RSS
>> drops after 'memhog' exits.
>>
> 
> Sounds promising, but...
> 
>> --- a/mm/page_reporting.h
>> +++ b/mm/page_reporting.h
>> @@ -10,9 +10,10 @@
>>   #include <linux/pgtable.h>
>>   #include <linux/scatterlist.h>
>>   
>> -#define PAGE_REPORTING_MIN_ORDER	pageblock_order
>> -
>>   #ifdef CONFIG_PAGE_REPORTING
>> +#define PAGE_REPORTING_MIN_ORDER	\
>> +	min_t(unsigned int, pageblock_order, (MAX_ORDER / 2))
>> +
>>   DECLARE_STATIC_KEY_FALSE(page_reporting_enabled);
>>   void __page_reporting_notify(void);
> 
> Could you please redo this as a regular old static function in
> page_reporting.c?  Bonus points for commenting its design ;)
> 

Thanks for your time to review, Andrew. Sorry for the delay and late
reply. Yes, I will do if needed after the discussion with David is
finalized.

Thanks,
Gavin