From: Gavin Shan <gshan@redhat.com>
To: Alexander Duyck <alexander.duyck@gmail.com>
Cc: linux-mm <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
David Hildenbrand <david@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
shan.gavin@gmail.com
Subject: Re: [PATCH v2 3/3] virtio_balloon: Specify page reporting order if needed
Date: Wed, 23 Jun 2021 10:47:30 +1000 [thread overview]
Message-ID: <3e449606-e02f-7c09-45e3-8d2401b53086@redhat.com> (raw)
In-Reply-To: <CAKgT0Ue461-yYEYSsSpLo-7xjK8aa3__2aAwJZ+CLy7_waC8Pg@mail.gmail.com>
On 6/23/21 3:44 AM, Alexander Duyck wrote:
> On Mon, Jun 21, 2021 at 10:49 PM Gavin Shan <gshan@redhat.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@redhat.com>
>> Cc: David Hildenbrand <david@redhat.com>
>> Cc: virtualization@lists.linux-foundation.org
>> Signed-off-by: Gavin Shan <gshan@redhat.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@fb.com>
>
Yes, It's something for later. Lets fix the particular case
(ARM64 and 64KB page size) for now.
Thanks,
Gavin
prev parent reply other threads:[~2021-06-22 22:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-22 7:49 [PATCH v2 0/3] mm/page_reporting: Make page reporting work on arm64 with 64KB page size Gavin Shan
2021-06-22 7:49 ` [PATCH v2 1/3] mm/page_reporting: Fix code style in __page_reporting_request() Gavin Shan
2021-06-22 7:49 ` [PATCH v2 2/3] mm/page_reporting: Allow driver to specify threshold Gavin Shan
2021-06-22 17:39 ` Alexander Duyck
2021-06-23 0:43 ` Gavin Shan
2021-06-22 7:49 ` [PATCH v2 3/3] virtio_balloon: Specify page reporting order if needed Gavin Shan
2021-06-22 17:44 ` Alexander Duyck
2021-06-23 0:47 ` Gavin Shan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3e449606-e02f-7c09-45e3-8d2401b53086@redhat.com \
--to=gshan@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.duyck@gmail.com \
--cc=anshuman.khandual@arm.com \
--cc=catalin.marinas@arm.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mst@redhat.com \
--cc=shan.gavin@gmail.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).