mbox series

[v5,0/4] mm/page_reporting: Make page reporting work on arm64 with 64KB page size

Message ID 20210625042150.46964-1-gshan@redhat.com (mailing list archive)
Headers show
Series mm/page_reporting: Make page reporting work on arm64 with 64KB page size | expand

Message

Gavin Shan June 25, 2021, 4:21 a.m. UTC
The page reporting threshold is currently equal to @pageblock_order, which
is 13 and 512MB on arm64 with 64KB base page size selected. The page
reporting won't be triggered if the freeing page can't come up with a free
area like that huge. The condition is hard to be met, especially when the
system memory becomes fragmented.

This series intends to solve the issue by having page reporting threshold
as 5 (2MB) on arm64 with 64KB base page size. The patches are organized as:

   PATCH[1/4] Fix some coding style in __page_reporting_request().
   PATCH[2/4] Represents page reporting order with variable so that it can
              be exported as module parameter.
   PATCH[3/4] Allows the device driver (e.g. virtio_balloon) to specify
              the page reporting order when the device info is registered.
   PATCH[4/4] Specifies the page reporting order to 5, corresponding to
              2MB in size on ARM64 when 64KB base page size is used.

Changelog
=========
v5:
   * Restore @page_reporting_order to @pageblock_order when
     device is registered in PATCH[2/4] to keep "git bisect"
     friendly at least.                                           (Alex)
v4:
   * Set @page_reporting_order to MAX_ORDER. Its value is
     specified by the driver or falls back to @pageblock_order
     when page reporting device is registered.                    (Alex)
   * Include "module.h" in page_reporting.c                       (Andrew)
v3:
   * Avoid overhead introduced by function all                    (Alex)
   * Export page reporting order as module parameter              (Gavin)
v2:
   * Rewrite the patches as Alex suggested                        (Alex)

Gavin Shan (4):
  mm/page_reporting: Fix code style in __page_reporting_request()
  mm/page_reporting: Export reporting order as module parameter
  mm/page_reporting: Allow driver to specify reporting
  virtio_balloon: Specify page reporting order if needed

 .../admin-guide/kernel-parameters.txt         |  6 +++++
 drivers/virtio/virtio_balloon.c               | 17 ++++++++++++++
 include/linux/page_reporting.h                |  3 +++
 mm/page_reporting.c                           | 22 +++++++++++++++----
 mm/page_reporting.h                           |  5 ++---
 5 files changed, 46 insertions(+), 7 deletions(-)

Comments

Michael S. Tsirkin June 25, 2021, 5:58 a.m. UTC | #1
On Fri, Jun 25, 2021 at 12:21:46PM +0800, Gavin Shan wrote:
> The page reporting threshold is currently equal to @pageblock_order, which
> is 13 and 512MB on arm64 with 64KB base page size selected. The page
> reporting won't be triggered if the freeing page can't come up with a free
> area like that huge. The condition is hard to be met, especially when the
> system memory becomes fragmented.
> 
> This series intends to solve the issue by having page reporting threshold
> as 5 (2MB) on arm64 with 64KB base page size. The patches are organized as:
> 
>    PATCH[1/4] Fix some coding style in __page_reporting_request().
>    PATCH[2/4] Represents page reporting order with variable so that it can
>               be exported as module parameter.
>    PATCH[3/4] Allows the device driver (e.g. virtio_balloon) to specify
>               the page reporting order when the device info is registered.
>    PATCH[4/4] Specifies the page reporting order to 5, corresponding to
>               2MB in size on ARM64 when 64KB base page size is used.

I sent comments on v4. They still apply I think. Want me to repeat them
here?

> Changelog
> =========
> v5:
>    * Restore @page_reporting_order to @pageblock_order when
>      device is registered in PATCH[2/4] to keep "git bisect"
>      friendly at least.                                           (Alex)
> v4:
>    * Set @page_reporting_order to MAX_ORDER. Its value is
>      specified by the driver or falls back to @pageblock_order
>      when page reporting device is registered.                    (Alex)
>    * Include "module.h" in page_reporting.c                       (Andrew)
> v3:
>    * Avoid overhead introduced by function all                    (Alex)
>    * Export page reporting order as module parameter              (Gavin)
> v2:
>    * Rewrite the patches as Alex suggested                        (Alex)
> 
> Gavin Shan (4):
>   mm/page_reporting: Fix code style in __page_reporting_request()
>   mm/page_reporting: Export reporting order as module parameter
>   mm/page_reporting: Allow driver to specify reporting
>   virtio_balloon: Specify page reporting order if needed
> 
>  .../admin-guide/kernel-parameters.txt         |  6 +++++
>  drivers/virtio/virtio_balloon.c               | 17 ++++++++++++++
>  include/linux/page_reporting.h                |  3 +++
>  mm/page_reporting.c                           | 22 +++++++++++++++----
>  mm/page_reporting.h                           |  5 ++---
>  5 files changed, 46 insertions(+), 7 deletions(-)
> 
> -- 
> 2.23.0
Gavin Shan June 25, 2021, 6:17 a.m. UTC | #2
On 6/25/21 3:58 PM, Michael S. Tsirkin wrote:
> On Fri, Jun 25, 2021 at 12:21:46PM +0800, Gavin Shan wrote:
>> The page reporting threshold is currently equal to @pageblock_order, which
>> is 13 and 512MB on arm64 with 64KB base page size selected. The page
>> reporting won't be triggered if the freeing page can't come up with a free
>> area like that huge. The condition is hard to be met, especially when the
>> system memory becomes fragmented.
>>
>> This series intends to solve the issue by having page reporting threshold
>> as 5 (2MB) on arm64 with 64KB base page size. The patches are organized as:
>>
>>     PATCH[1/4] Fix some coding style in __page_reporting_request().
>>     PATCH[2/4] Represents page reporting order with variable so that it can
>>                be exported as module parameter.
>>     PATCH[3/4] Allows the device driver (e.g. virtio_balloon) to specify
>>                the page reporting order when the device info is registered.
>>     PATCH[4/4] Specifies the page reporting order to 5, corresponding to
>>                2MB in size on ARM64 when 64KB base page size is used.
> 
> I sent comments on v4. They still apply I think. Want me to repeat them
> here?
> 

Thanks for your comments, Michael. I've replied to your comments
through v4. There are some future work as Alex and David pointed
out before: In order to remove the hack in virtio-memballoon, the
VMM needs to report the page reporting order. I will keep working
on this when I have spare time.

Thanks,
Gavin

>> Changelog
>> =========
>> v5:
>>     * Restore @page_reporting_order to @pageblock_order when
>>       device is registered in PATCH[2/4] to keep "git bisect"
>>       friendly at least.                                           (Alex)
>> v4:
>>     * Set @page_reporting_order to MAX_ORDER. Its value is
>>       specified by the driver or falls back to @pageblock_order
>>       when page reporting device is registered.                    (Alex)
>>     * Include "module.h" in page_reporting.c                       (Andrew)
>> v3:
>>     * Avoid overhead introduced by function all                    (Alex)
>>     * Export page reporting order as module parameter              (Gavin)
>> v2:
>>     * Rewrite the patches as Alex suggested                        (Alex)
>>
>> Gavin Shan (4):
>>    mm/page_reporting: Fix code style in __page_reporting_request()
>>    mm/page_reporting: Export reporting order as module parameter
>>    mm/page_reporting: Allow driver to specify reporting
>>    virtio_balloon: Specify page reporting order if needed
>>
>>   .../admin-guide/kernel-parameters.txt         |  6 +++++
>>   drivers/virtio/virtio_balloon.c               | 17 ++++++++++++++
>>   include/linux/page_reporting.h                |  3 +++
>>   mm/page_reporting.c                           | 22 +++++++++++++++----
>>   mm/page_reporting.h                           |  5 ++---
>>   5 files changed, 46 insertions(+), 7 deletions(-)
>>
>> -- 
>> 2.23.0
>
Alexander Duyck June 25, 2021, 2:18 p.m. UTC | #3
On Thu, Jun 24, 2021 at 7:20 PM Gavin Shan <gshan@redhat.com> wrote:
>
> The page reporting threshold is currently equal to @pageblock_order, which
> is 13 and 512MB on arm64 with 64KB base page size selected. The page
> reporting won't be triggered if the freeing page can't come up with a free
> area like that huge. The condition is hard to be met, especially when the
> system memory becomes fragmented.
>
> This series intends to solve the issue by having page reporting threshold
> as 5 (2MB) on arm64 with 64KB base page size. The patches are organized as:
>
>    PATCH[1/4] Fix some coding style in __page_reporting_request().
>    PATCH[2/4] Represents page reporting order with variable so that it can
>               be exported as module parameter.
>    PATCH[3/4] Allows the device driver (e.g. virtio_balloon) to specify
>               the page reporting order when the device info is registered.
>    PATCH[4/4] Specifies the page reporting order to 5, corresponding to
>               2MB in size on ARM64 when 64KB base page size is used.
>
> Changelog
> =========
> v5:
>    * Restore @page_reporting_order to @pageblock_order when
>      device is registered in PATCH[2/4] to keep "git bisect"
>      friendly at least.                                           (Alex)

These latest changes address the concerns I had.

Thanks.

- Alex
Gavin Shan June 28, 2021, 9:45 a.m. UTC | #4
On 6/26/21 12:18 AM, Alexander Duyck wrote:
> On Thu, Jun 24, 2021 at 7:20 PM Gavin Shan <gshan@redhat.com> wrote:
>>
>> The page reporting threshold is currently equal to @pageblock_order, which
>> is 13 and 512MB on arm64 with 64KB base page size selected. The page
>> reporting won't be triggered if the freeing page can't come up with a free
>> area like that huge. The condition is hard to be met, especially when the
>> system memory becomes fragmented.
>>
>> This series intends to solve the issue by having page reporting threshold
>> as 5 (2MB) on arm64 with 64KB base page size. The patches are organized as:
>>
>>     PATCH[1/4] Fix some coding style in __page_reporting_request().
>>     PATCH[2/4] Represents page reporting order with variable so that it can
>>                be exported as module parameter.
>>     PATCH[3/4] Allows the device driver (e.g. virtio_balloon) to specify
>>                the page reporting order when the device info is registered.
>>     PATCH[4/4] Specifies the page reporting order to 5, corresponding to
>>                2MB in size on ARM64 when 64KB base page size is used.
>>
>> Changelog
>> =========
>> v5:
>>     * Restore @page_reporting_order to @pageblock_order when
>>       device is registered in PATCH[2/4] to keep "git bisect"
>>       friendly at least.                                           (Alex)
> 
> These latest changes address the concerns I had.
> 

Thanks again for your review, Alex. However, v4 was merged and it's fine
since v5 only resolves 'git-bisect' friendly issue on PATCH[v4 2/4].

Thanks,
Gavin