linux-kernel - Re: [PATCH v2 3/3] virtio_balloon: Specify page reporting order if needed

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]

Date:   Wed, 23 Jun 2021 10:47:30 +1000
From:   Gavin Shan <gshan@...hat.com>
To:     Alexander Duyck <alexander.duyck@...il.com>
Cc:     linux-mm <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>,
        David Hildenbrand <david@...hat.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, shan.gavin@...il.com
Subject: Re: [PATCH v2 3/3] virtio_balloon: Specify page reporting order if
 needed

On 6/23/21 3:44 AM, Alexander Duyck wrote:
> On Mon, Jun 21, 2021 at 10:49 PM Gavin Shan <gshan@...hat.com> wrote:
>>
>> The page reporting won't be triggered if the freeing page can't come
>> up with a free area, whose size is equal or bigger than the threshold
>> (page reporting order). The default page reporting order, equal to
>> @pageblock_order, is too huge on some architectures to trigger page
>> reporting. One example is ARM64 when 64KB base page size is used.
>>
>>        PAGE_SIZE:          64KB
>>        pageblock_order:    13       (512MB)
>>        MAX_ORDER:          14
>>
>> This specifies the page reporting order to 5 (2MB) for this specific
>> case so that page reporting can be triggered.
>>
>> Cc: Michael S. Tsirkin <mst@...hat.com>
>> Cc: David Hildenbrand <david@...hat.com>
>> Cc: virtualization@...ts.linux-foundation.org
>> Signed-off-by: Gavin Shan <gshan@...hat.com>
>> ---
>>   drivers/virtio/virtio_balloon.c | 17 +++++++++++++++++
>>   1 file changed, 17 insertions(+)
>>
>> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
>> index 510e9318854d..fd419780cc23 100644
>> --- a/drivers/virtio/virtio_balloon.c
>> +++ b/drivers/virtio/virtio_balloon.c
>> @@ -993,6 +993,23 @@ static int virtballoon_probe(struct virtio_device *vdev)
>>                          goto out_unregister_oom;
>>                  }
>>
>> +               /*
>> +                * The default page reporting order is @pageblock_order, which
>> +                * corresponds to 512MB in size on ARM64 when 64KB base page
>> +                * size is used. The page reporting won't be triggered if the
>> +                * freeing page can't come up with a free area like that huge.
>> +                * So we specify the page reporting order to 5, corresponding
>> +                * to 2MB. It helps to avoid THP splitting if 4KB base page
>> +                * size is used by host.
>> +                *
>> +                * Ideallh, the page reporting order is selected based on the
> 
> "Ideally"
> 

Yeah, I noticed it right after the patch was posted. Will be fixed
in v3.

>> +                * host's base page size. However, it needs more work to report
>> +                * that value. The hardcoded order would be fine currently.
>> +                */
>> +#if defined(CONFIG_ARM64) && defined(CONFIG_ARM64_64K_PAGES)
>> +               vb->pr_dev_info.order = 5;
>> +#endif
>> +
>>                  err = page_reporting_register(&vb->pr_dev_info);
>>                  if (err)
>>                          goto out_unregister_oom;
> 
> This works for now. However my preference would be to look into seeing
> if we can add a value that the host can report that would override the
> value you selected here. Then in situations where the host has a
> smaller THP page size then the guest it can report the preferred
> reporting order via the virtio_balloon interface and have greater
> flexibility.
> 
> Reviewed-by: Alexander Duyck <alexanderduyck@...com>
> 

Yes, It's something for later. Lets fix the particular case
(ARM64 and 64KB page size) for now.

Thanks,
Gavin