linux-kernel - Re: [PATCH v4 4/4] 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:   Fri, 25 Jun 2021 01:57:19 -0400
From:   "Michael S. Tsirkin" <mst@...hat.com>
To:     Gavin Shan <gshan@...hat.com>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        alexander.duyck@...il.com, david@...hat.com,
        akpm@...ux-foundation.org, anshuman.khandual@....com,
        catalin.marinas@....com, will@...nel.org, shan.gavin@...il.com
Subject: Re: [PATCH v4 4/4] virtio_balloon: Specify page reporting order if
 needed

On Fri, Jun 25, 2021 at 09:47:10AM +0800, Gavin Shan 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>
> Reviewed-by: Alexander Duyck <alexanderduyck@...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..47dce91f788c 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.
> +		 *
> +		 * Ideally, the page reporting order is selected based on the
> +		 * host's base page size. However, it needs more work to report
> +		 * that value. The hard-coded order would be fine currently.
> +		 */
> +#if defined(CONFIG_ARM64) && defined(CONFIG_ARM64_64K_PAGES)
> +		vb->pr_dev_info.order = 5;
> +#endif
> +

I was hoping we can get rid of the hacks in virtio with the new
parameter and logic in mm core. Why not?

>  		err = page_reporting_register(&vb->pr_dev_info);
>  		if (err)
>  			goto out_unregister_oom;
> -- 
> 2.23.0