[v9,0/8] stg mail -e --version=v9 \

Message

Alexander Duyck Sept. 7, 2019, 5:25 p.m. UTC

--to=[e-mail] \
--to=[e-mail] \
--to=[e-mail] \
--to=[e-mail] \
--to=[e-mail] \
--to=[e-mail] \
--to=[e-mail] \
--to=[e-mail] \
--to=[e-mail] \
--cc=[e-mail] \
--cc=[e-mail] \
--cc=[e-mail] \
--cc=[e-mail] \
--cc=[e-mail] \
--cc=[e-mail] \
--cc=[e-mail] \
--cc=[e-mail] \
--cc=[e-mail] \
--cc=[e-mail] \
--to=[e-mail] \
--to=[e-mail] \
--to=[e-mail] \
--to=[e-mail] \
--to=[e-mail] \
--cc=[e-mail]  \
--cc=[e-mail] \
--cc=[e-mail] \
--cc=[e-mail] \
01-mm-add-per-cpu-logic-to-page..08-virtio-balloon-add-support-for

mm / virtio: Provide support for unused page reporting

This series provides an asynchronous means of reporting to a hypervisor
that a guest page is no longer in use and can have the data associated
with it dropped. To do this I have implemented functionality that allows
for what I am referring to as unused page reporting

The functionality for this is fairly simple. When enabled it will allocate
statistics to track the number of reported pages in a given free area.
When the number of free pages exceeds this value plus a high water value,
currently 32, it will begin performing page reporting which consists of
pulling pages off of free list and placing them into a scatter list. The
scatterlist is then given to the page reporting device and it will perform
the required action to make the pages "reported", in the case of
virtio-balloon this results in the pages being madvised as MADV_DONTNEED
and as such they are forced out of the guest. After this they are placed
back on the free list, and an additional bit is added if they are not
merged indicating that they are a reported buddy page instead of a
standard buddy page. The cycle then repeats with additional non-reported
pages being pulled until the free areas all consist of reported pages.

I am leaving a number of things hard-coded such as limiting the lowest
order processed to PAGEBLOCK_ORDER, and have left it up to the guest to
determine what the limit is on how many pages it wants to allocate to
process the hints. The upper limit for this is based on the size of the
queue used to store the scattergather list.

My primary testing has just been to verify the memory is being freed after
allocation by running memhog 40g on a 40g guest and watching the total
free memory via /proc/meminfo on the host. With this I have verified most
of the memory is freed after each iteration. As far as performance I have
been mainly focusing on the will-it-scale/page_fault1 test running with
16 vcpus. I have modified it to use Transparent Huge Pages. With this I
see almost no difference, -0.08%, with the patches applied and the feature
disabled. I see a regression of -0.86% with the feature enabled, but the
madvise disabled in the hypervisor due to a device being assigned. With
the feature fully enabled I see a regression of -3.27% versus the baseline
without these patches applied. In my testing I found that most of the
overhead was due to the page zeroing that comes as a result of the pages
having to be faulted back into the guest.

One side effect of these patches is that the guest becomes much more
resilient in terms of NUMA locality. With the pages being freed and then
reallocated when used it allows for the pages to be much closer to the
active thread, and as a result there can be situations where this patch
set will out-perform the stock kernel when the guest memory is not local
to the guest vCPUs. To avoid that in my testing I set the affinity of all
the vCPUs and QEMU instance to the same node.

I have not included the QEMU patches with this set as they haven't really
changed in the last several revisions. If needed they can be located with
the v8 patchset.

Changes from the RFC:
https://lore.kernel.org/lkml/[e-mail]/
Moved aeration requested flag out of aerator and into zone->flags.
Moved boundary out of free_area and into local variables for aeration.
Moved aeration cycle out of interrupt and into workqueue.
Left nr_free as total pages instead of splitting it between raw and aerated.
Combined size and physical address values in virtio ring into one 64b value.

Changes from v1:
https://lore.kernel.org/lkml/[e-mail]/
Dropped "waste page treatment" in favor of "page hinting"
Renamed files and functions from "aeration" to "page_hinting"
Moved from page->lru list to scatterlist
Replaced wait on refcnt in shutdown with RCU and cancel_delayed_work_sync
Virtio now uses scatterlist directly instead of intermediate array
Moved stats out of free_area, now in separate area and pointed to from zone
Merged patch 5 into patch 4 to improve review-ability
Updated various code comments throughout

Changes from v2:
https://lore.kernel.org/lkml/[e-mail]/
Dropped "page hinting" in favor of "page reporting"
Renamed files from "hinting" to "reporting"
Replaced "Hinted" page type with "Reported" page flag
Added support for page poisoning while hinting is active
Add QEMU patch that implements PAGE_POISON feature

Changes from v3:
https://lore.kernel.org/lkml/[e-mail]/
Added mutex lock around page reporting startup and shutdown
Fixed reference to "page aeration" in patch 2
Split page reporting function bit out into separate QEMU patch
Limited capacity of scatterlist to vq size - 1 instead of vq size
Added exception handling for case of virtio descriptor allocation failure

Changes from v4:
https://lore.kernel.org/lkml/[e-mail]/
Replaced spin_(un)lock with spin_(un)lock_irq in page_reporting_cycle()
Dropped if/continue for ternary operator in page_reporting_process()
Added checks for isolate and cma types to for_each_reporting_migratetype_order
Added virtio-dev, Michal Hocko, and Oscar Salvador to to:/cc:
Rebased on latest linux-next and QEMU git trees

Changes from v5:
https://lore.kernel.org/lkml/[e-mail]/
Replaced spin_(un)lock with spin_(un)lock_irq in page_reporting_startup()
Updated shuffle code to use "shuffle_pick_tail" and updated patch description
Dropped storage of order and migratettype while page is being reported
Used get_pfnblock_migratetype to determine migratetype of page
Renamed put_reported_page to free_reported_page, added order as argument
Dropped check for CMA type as I believe we should be reporting those
Added code to allow moving of reported pages into and out of isolation
Defined page reporting order as minimum of Huge Page size vs MAX_ORDER - 1
Cleaned up use of static branch usage for page_reporting_notify_enabled

Changes from v6:
https://lore.kernel.org/lkml/[e-mail]/
Rebased on linux-next for 20190903
Added jump label to __page_reporting_request so we release RCU read lock
Removed "- 1" from capacity limit based on virtio ring
Added code to verify capacity is non-zero or return error on startup

Changes from v7:
https://lore.kernel.org/lkml/[e-mail]/
Updated poison fixes to clear flag if "nosanity" is enabled in kernel config
Split shuffle per-cpu optimization into separate patch
Moved check for !phdev->capacity into reporting patch where it belongs
Added Reviewed-by tags received for v7

Changes from v8:
https://lore.kernel.org/lkml/[e-mail]/
Added patch that moves HPAGE_SIZE definition for ARM64 to match other archs
Switch back to using pageblock_order instead of HUGETLB_ORDER and MAX_ORDER - 1
Boundary allocation now dynamic to support HUGETLB_PAGE_SIZE_VARIABLE option
Made use of existing code/functions to reduce size of move_to_boundary function
Dropped unused zone pointer from add_to/del_from_boundary functions
Added additional possible mm and arm64 people as reviewers to Cc
Added Reviewed-by tags received for v8
Fixed missing parameter in kerneldoc

---

Alexander Duyck (8):
      mm: Add per-cpu logic to page shuffling
      mm: Adjust shuffle code to allow for future coalescing
      mm: Move set/get_pcppage_migratetype to mmzone.h
      mm: Use zone and order instead of free area in free_list manipulators
      arm64: Move hugetlb related definitions out of pgtable.h to page-defs.h
      mm: Introduce Reported pages
      virtio-balloon: Pull page poisoning config out of free page hinting
      virtio-balloon: Add support for providing unused page reports to host


 arch/arm64/include/asm/page-def.h   |    9 +
 arch/arm64/include/asm/pgtable.h    |    9 -
 drivers/virtio/Kconfig              |    1 
 drivers/virtio/virtio_balloon.c     |   87 ++++++++-
 include/linux/mmzone.h              |  124 ++++++++----
 include/linux/page-flags.h          |   11 +
 include/linux/page_reporting.h      |  178 +++++++++++++++++
 include/uapi/linux/virtio_balloon.h |    1 
 mm/Kconfig                          |    5 
 mm/Makefile                         |    1 
 mm/internal.h                       |   18 ++
 mm/memory_hotplug.c                 |    1 
 mm/page_alloc.c                     |  217 +++++++++++++++------
 mm/page_reporting.c                 |  358 +++++++++++++++++++++++++++++++++++
 mm/shuffle.c                        |   40 ++--
 mm/shuffle.h                        |   12 +
 16 files changed, 931 insertions(+), 141 deletions(-)
 create mode 100644 include/linux/page_reporting.h
 create mode 100644 mm/page_reporting.c

--

Comments

Alexander Duyck Sept. 7, 2019, 5:34 p.m. UTC | #1

Sorry about that. Looks like I fat fingered things and copied the
command line into the cover page. I corrected the subject here, and
pulled the command line out of the message below.

- Alex

On Sat, Sep 7, 2019 at 10:25 AM Alexander Duyck
<[e-mail]> wrote:
> This series provides an asynchronous means of reporting to a hypervisor
> that a guest page is no longer in use and can have the data associated
> with it dropped. To do this I have implemented functionality that allows
> for what I am referring to as unused page reporting
>
> The functionality for this is fairly simple. When enabled it will allocate
> statistics to track the number of reported pages in a given free area.
> When the number of free pages exceeds this value plus a high water value,
> currently 32, it will begin performing page reporting which consists of
> pulling pages off of free list and placing them into a scatter list. The
> scatterlist is then given to the page reporting device and it will perform
> the required action to make the pages "reported", in the case of
> virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> and as such they are forced out of the guest. After this they are placed
> back on the free list, and an additional bit is added if they are not
> merged indicating that they are a reported buddy page instead of a
> standard buddy page. The cycle then repeats with additional non-reported
> pages being pulled until the free areas all consist of reported pages.
>
> I am leaving a number of things hard-coded such as limiting the lowest
> order processed to PAGEBLOCK_ORDER, and have left it up to the guest to
> determine what the limit is on how many pages it wants to allocate to
> process the hints. The upper limit for this is based on the size of the
> queue used to store the scattergather list.
>
> My primary testing has just been to verify the memory is being freed after
> allocation by running memhog 40g on a 40g guest and watching the total
> free memory via /proc/meminfo on the host. With this I have verified most
> of the memory is freed after each iteration. As far as performance I have
> been mainly focusing on the will-it-scale/page_fault1 test running with
> 16 vcpus. I have modified it to use Transparent Huge Pages. With this I
> see almost no difference, -0.08%, with the patches applied and the feature
> disabled. I see a regression of -0.86% with the feature enabled, but the
> madvise disabled in the hypervisor due to a device being assigned. With
> the feature fully enabled I see a regression of -3.27% versus the baseline
> without these patches applied. In my testing I found that most of the
> overhead was due to the page zeroing that comes as a result of the pages
> having to be faulted back into the guest.
>
> One side effect of these patches is that the guest becomes much more
> resilient in terms of NUMA locality. With the pages being freed and then
> reallocated when used it allows for the pages to be much closer to the
> active thread, and as a result there can be situations where this patch
> set will out-perform the stock kernel when the guest memory is not local
> to the guest vCPUs. To avoid that in my testing I set the affinity of all
> the vCPUs and QEMU instance to the same node.
>
> I have not included the QEMU patches with this set as they haven't really
> changed in the last several revisions. If needed they can be located with
> the v8 patchset.
>
> Changes from the RFC:
> https://lore.kernel.org/lkml/[e-mail]/
> Moved aeration requested flag out of aerator and into zone->flags.
> Moved boundary out of free_area and into local variables for aeration.
> Moved aeration cycle out of interrupt and into workqueue.
> Left nr_free as total pages instead of splitting it between raw and aerated.
> Combined size and physical address values in virtio ring into one 64b value.
>
> Changes from v1:
> https://lore.kernel.org/lkml/[e-mail]/
> Dropped "waste page treatment" in favor of "page hinting"
> Renamed files and functions from "aeration" to "page_hinting"
> Moved from page->lru list to scatterlist
> Replaced wait on refcnt in shutdown with RCU and cancel_delayed_work_sync
> Virtio now uses scatterlist directly instead of intermediate array
> Moved stats out of free_area, now in separate area and pointed to from zone
> Merged patch 5 into patch 4 to improve review-ability
> Updated various code comments throughout
>
> Changes from v2:
> https://lore.kernel.org/lkml/[e-mail]/
> Dropped "page hinting" in favor of "page reporting"
> Renamed files from "hinting" to "reporting"
> Replaced "Hinted" page type with "Reported" page flag
> Added support for page poisoning while hinting is active
> Add QEMU patch that implements PAGE_POISON feature
>
> Changes from v3:
> https://lore.kernel.org/lkml/[e-mail]/
> Added mutex lock around page reporting startup and shutdown
> Fixed reference to "page aeration" in patch 2
> Split page reporting function bit out into separate QEMU patch
> Limited capacity of scatterlist to vq size - 1 instead of vq size
> Added exception handling for case of virtio descriptor allocation failure
>
> Changes from v4:
> https://lore.kernel.org/lkml/[e-mail]/
> Replaced spin_(un)lock with spin_(un)lock_irq in page_reporting_cycle()
> Dropped if/continue for ternary operator in page_reporting_process()
> Added checks for isolate and cma types to for_each_reporting_migratetype_order
> Added virtio-dev, Michal Hocko, and Oscar Salvador to to:/cc:
> Rebased on latest linux-next and QEMU git trees
>
> Changes from v5:
> https://lore.kernel.org/lkml/[e-mail]/
> Replaced spin_(un)lock with spin_(un)lock_irq in page_reporting_startup()
> Updated shuffle code to use "shuffle_pick_tail" and updated patch description
> Dropped storage of order and migratettype while page is being reported
> Used get_pfnblock_migratetype to determine migratetype of page
> Renamed put_reported_page to free_reported_page, added order as argument
> Dropped check for CMA type as I believe we should be reporting those
> Added code to allow moving of reported pages into and out of isolation
> Defined page reporting order as minimum of Huge Page size vs MAX_ORDER - 1
> Cleaned up use of static branch usage for page_reporting_notify_enabled
>
> Changes from v6:
> https://lore.kernel.org/lkml/[e-mail]/
> Rebased on linux-next for 20190903
> Added jump label to __page_reporting_request so we release RCU read lock
> Removed "- 1" from capacity limit based on virtio ring
> Added code to verify capacity is non-zero or return error on startup
>
> Changes from v7:
> https://lore.kernel.org/lkml/[e-mail]/
> Updated poison fixes to clear flag if "nosanity" is enabled in kernel config
> Split shuffle per-cpu optimization into separate patch
> Moved check for !phdev->capacity into reporting patch where it belongs
> Added Reviewed-by tags received for v7
>
> Changes from v8:
> https://lore.kernel.org/lkml/[e-mail]/
> Added patch that moves HPAGE_SIZE definition for ARM64 to match other archs
> Switch back to using pageblock_order instead of HUGETLB_ORDER and MAX_ORDER - 1
> Boundary allocation now dynamic to support HUGETLB_PAGE_SIZE_VARIABLE option
> Made use of existing code/functions to reduce size of move_to_boundary function
> Dropped unused zone pointer from add_to/del_from_boundary functions
> Added additional possible mm and arm64 people as reviewers to Cc
> Added Reviewed-by tags received for v8
> Fixed missing parameter in kerneldoc
>
> ---
>
> Alexander Duyck (8):
>       mm: Add per-cpu logic to page shuffling
>       mm: Adjust shuffle code to allow for future coalescing
>       mm: Move set/get_pcppage_migratetype to mmzone.h
>       mm: Use zone and order instead of free area in free_list manipulators
>       arm64: Move hugetlb related definitions out of pgtable.h to page-defs.h
>       mm: Introduce Reported pages
>       virtio-balloon: Pull page poisoning config out of free page hinting
>       virtio-balloon: Add support for providing unused page reports to host
>
>
>  arch/arm64/include/asm/page-def.h   |    9 +
>  arch/arm64/include/asm/pgtable.h    |    9 -
>  drivers/virtio/Kconfig              |    1
>  drivers/virtio/virtio_balloon.c     |   87 ++++++++-
>  include/linux/mmzone.h              |  124 ++++++++----
>  include/linux/page-flags.h          |   11 +
>  include/linux/page_reporting.h      |  178 +++++++++++++++++
>  include/uapi/linux/virtio_balloon.h |    1
>  mm/Kconfig                          |    5
>  mm/Makefile                         |    1
>  mm/internal.h                       |   18 ++
>  mm/memory_hotplug.c                 |    1
>  mm/page_alloc.c                     |  217 +++++++++++++++------
>  mm/page_reporting.c                 |  358 +++++++++++++++++++++++++++++++++++
>  mm/shuffle.c                        |   40 ++--
>  mm/shuffle.h                        |   12 +
>  16 files changed, 931 insertions(+), 141 deletions(-)
>  create mode 100644 include/linux/page_reporting.h
>  create mode 100644 mm/page_reporting.c
>
> --

Michal Hocko Sept. 10, 2019, 12:42 p.m. UTC | #2

I wanted to review "mm: Introduce Reported pages" just realize that I
have no clue on what is going on so returned to the cover and it didn't
really help much. I am completely unfamiliar with virtio so please bear
with me.

On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
[...]
> This series provides an asynchronous means of reporting to a hypervisor
> that a guest page is no longer in use and can have the data associated
> with it dropped. To do this I have implemented functionality that allows
> for what I am referring to as unused page reporting
> 
> The functionality for this is fairly simple. When enabled it will allocate
> statistics to track the number of reported pages in a given free area.
> When the number of free pages exceeds this value plus a high water value,
> currently 32, it will begin performing page reporting which consists of
> pulling pages off of free list and placing them into a scatter list. The
> scatterlist is then given to the page reporting device and it will perform
> the required action to make the pages "reported", in the case of
> virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> and as such they are forced out of the guest. After this they are placed
> back on the free list,

And here I am reallly lost because "forced out of the guest" makes me
feel that those pages are no longer usable by the guest. So how come you
can add them back to the free list. I suspect understanding this part
will allow me to understand why we have to mark those pages and prevent
merging.

> and an additional bit is added if they are not
> merged indicating that they are a reported buddy page instead of a
> standard buddy page. The cycle then repeats with additional non-reported
> pages being pulled until the free areas all consist of reported pages.

Alexander Duyck Sept. 10, 2019, 2:42 p.m. UTC | #3

On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <[e-mail]> wrote:
>
> I wanted to review "mm: Introduce Reported pages" just realize that I
> have no clue on what is going on so returned to the cover and it didn't
> really help much. I am completely unfamiliar with virtio so please bear
> with me.
>
> On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> [...]
> > This series provides an asynchronous means of reporting to a hypervisor
> > that a guest page is no longer in use and can have the data associated
> > with it dropped. To do this I have implemented functionality that allows
> > for what I am referring to as unused page reporting
> >
> > The functionality for this is fairly simple. When enabled it will allocate
> > statistics to track the number of reported pages in a given free area.
> > When the number of free pages exceeds this value plus a high water value,
> > currently 32, it will begin performing page reporting which consists of
> > pulling pages off of free list and placing them into a scatter list. The
> > scatterlist is then given to the page reporting device and it will perform
> > the required action to make the pages "reported", in the case of
> > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > and as such they are forced out of the guest. After this they are placed
> > back on the free list,
>
> And here I am reallly lost because "forced out of the guest" makes me
> feel that those pages are no longer usable by the guest. So how come you
> can add them back to the free list. I suspect understanding this part
> will allow me to understand why we have to mark those pages and prevent
> merging.

Basically as the paragraph above mentions "forced out of the guest"
really is just the hypervisor calling MADV_DONTNEED on the page in
question. So the behavior is the same as any userspace application
that calls MADV_DONTNEED where the contents are no longer accessible
from userspace and attempting to access them will result in a fault
and the page being populated with a zero fill on-demand page, or a
copy of the file contents if the memory is file backed.

Michal Hocko Sept. 10, 2019, 2:47 p.m. UTC | #4

On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <[e-mail]> wrote:
> >
> > I wanted to review "mm: Introduce Reported pages" just realize that I
> > have no clue on what is going on so returned to the cover and it didn't
> > really help much. I am completely unfamiliar with virtio so please bear
> > with me.
> >
> > On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> > [...]
> > > This series provides an asynchronous means of reporting to a hypervisor
> > > that a guest page is no longer in use and can have the data associated
> > > with it dropped. To do this I have implemented functionality that allows
> > > for what I am referring to as unused page reporting
> > >
> > > The functionality for this is fairly simple. When enabled it will allocate
> > > statistics to track the number of reported pages in a given free area.
> > > When the number of free pages exceeds this value plus a high water value,
> > > currently 32, it will begin performing page reporting which consists of
> > > pulling pages off of free list and placing them into a scatter list. The
> > > scatterlist is then given to the page reporting device and it will perform
> > > the required action to make the pages "reported", in the case of
> > > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > > and as such they are forced out of the guest. After this they are placed
> > > back on the free list,
> >
> > And here I am reallly lost because "forced out of the guest" makes me
> > feel that those pages are no longer usable by the guest. So how come you
> > can add them back to the free list. I suspect understanding this part
> > will allow me to understand why we have to mark those pages and prevent
> > merging.
> 
> Basically as the paragraph above mentions "forced out of the guest"
> really is just the hypervisor calling MADV_DONTNEED on the page in
> question. So the behavior is the same as any userspace application
> that calls MADV_DONTNEED where the contents are no longer accessible
> from userspace and attempting to access them will result in a fault
> and the page being populated with a zero fill on-demand page, or a
> copy of the file contents if the memory is file backed.

As I've said I have no idea about virt so this doesn't really tell me
much. Does that mean that if somebody allocates such a page and tries to
access it then virt will handle a fault and bring it back?

Alexander Duyck Sept. 10, 2019, 4:05 p.m. UTC | #5

On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <[e-mail]> wrote:
>
> On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <[e-mail]> wrote:
> > >
> > > I wanted to review "mm: Introduce Reported pages" just realize that I
> > > have no clue on what is going on so returned to the cover and it didn't
> > > really help much. I am completely unfamiliar with virtio so please bear
> > > with me.
> > >
> > > On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> > > [...]
> > > > This series provides an asynchronous means of reporting to a hypervisor
> > > > that a guest page is no longer in use and can have the data associated
> > > > with it dropped. To do this I have implemented functionality that allows
> > > > for what I am referring to as unused page reporting
> > > >
> > > > The functionality for this is fairly simple. When enabled it will allocate
> > > > statistics to track the number of reported pages in a given free area.
> > > > When the number of free pages exceeds this value plus a high water value,
> > > > currently 32, it will begin performing page reporting which consists of
> > > > pulling pages off of free list and placing them into a scatter list. The
> > > > scatterlist is then given to the page reporting device and it will perform
> > > > the required action to make the pages "reported", in the case of
> > > > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > > > and as such they are forced out of the guest. After this they are placed
> > > > back on the free list,
> > >
> > > And here I am reallly lost because "forced out of the guest" makes me
> > > feel that those pages are no longer usable by the guest. So how come you
> > > can add them back to the free list. I suspect understanding this part
> > > will allow me to understand why we have to mark those pages and prevent
> > > merging.
> >
> > Basically as the paragraph above mentions "forced out of the guest"
> > really is just the hypervisor calling MADV_DONTNEED on the page in
> > question. So the behavior is the same as any userspace application
> > that calls MADV_DONTNEED where the contents are no longer accessible
> > from userspace and attempting to access them will result in a fault
> > and the page being populated with a zero fill on-demand page, or a
> > copy of the file contents if the memory is file backed.
>
> As I've said I have no idea about virt so this doesn't really tell me
> much. Does that mean that if somebody allocates such a page and tries to
> access it then virt will handle a fault and bring it back?

Actually I am probably describing too much as the MADV_DONTNEED is the
hypervisor behavior in response to the virtio-balloon notification. A
more thorough explanation of it can be found by just running "man
madvise", probably best just to leave it at that since I am probably
confusing things by describing hypervisor behavior in a kernel patch
set.

For the most part all the page reporting really does is provide a way
to incrementally identify unused regions of memory in the buddy
allocator. That in turn is used by virtio-balloon in a polling thread
to report to the hypervisor what pages are not in use so that it can
make a decision on what to do with the pages now that it knows they
are unused.

All this is providing is just a report and it is optional if the
hypervisor will act on it or not. If the hypervisor takes some sort of
action on the page, then the expectation is that the hypervisor will
use some sort of mechanism such as a page fault to discover when the
page is used again.

Dr. David Alan Gilbert Sept. 10, 2019, 4:18 p.m. UTC | #6

* Alexander Duyck ([e-mail]) wrote:
> On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <[e-mail]> wrote:
> >
> > On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> > > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <[e-mail]> wrote:
> > > >
> > > > I wanted to review "mm: Introduce Reported pages" just realize that I
> > > > have no clue on what is going on so returned to the cover and it didn't
> > > > really help much. I am completely unfamiliar with virtio so please bear
> > > > with me.
> > > >
> > > > On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> > > > [...]
> > > > > This series provides an asynchronous means of reporting to a hypervisor
> > > > > that a guest page is no longer in use and can have the data associated
> > > > > with it dropped. To do this I have implemented functionality that allows
> > > > > for what I am referring to as unused page reporting
> > > > >
> > > > > The functionality for this is fairly simple. When enabled it will allocate
> > > > > statistics to track the number of reported pages in a given free area.
> > > > > When the number of free pages exceeds this value plus a high water value,
> > > > > currently 32, it will begin performing page reporting which consists of
> > > > > pulling pages off of free list and placing them into a scatter list. The
> > > > > scatterlist is then given to the page reporting device and it will perform
> > > > > the required action to make the pages "reported", in the case of
> > > > > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > > > > and as such they are forced out of the guest. After this they are placed
> > > > > back on the free list,
> > > >
> > > > And here I am reallly lost because "forced out of the guest" makes me
> > > > feel that those pages are no longer usable by the guest. So how come you
> > > > can add them back to the free list. I suspect understanding this part
> > > > will allow me to understand why we have to mark those pages and prevent
> > > > merging.
> > >
> > > Basically as the paragraph above mentions "forced out of the guest"
> > > really is just the hypervisor calling MADV_DONTNEED on the page in
> > > question. So the behavior is the same as any userspace application
> > > that calls MADV_DONTNEED where the contents are no longer accessible
> > > from userspace and attempting to access them will result in a fault
> > > and the page being populated with a zero fill on-demand page, or a
> > > copy of the file contents if the memory is file backed.
> >
> > As I've said I have no idea about virt so this doesn't really tell me
> > much. Does that mean that if somebody allocates such a page and tries to
> > access it then virt will handle a fault and bring it back?
> 
> Actually I am probably describing too much as the MADV_DONTNEED is the
> hypervisor behavior in response to the virtio-balloon notification. A
> more thorough explanation of it can be found by just running "man
> madvise", probably best just to leave it at that since I am probably
> confusing things by describing hypervisor behavior in a kernel patch
> set.
> 
> For the most part all the page reporting really does is provide a way
> to incrementally identify unused regions of memory in the buddy
> allocator. That in turn is used by virtio-balloon in a polling thread
> to report to the hypervisor what pages are not in use so that it can
> make a decision on what to do with the pages now that it knows they
> are unused.
> 
> All this is providing is just a report and it is optional if the
> hypervisor will act on it or not. If the hypervisor takes some sort of
> action on the page, then the expectation is that the hypervisor will
> use some sort of mechanism such as a page fault to discover when the
> page is used again.

OK, that's interestingly different (but OK) from some other schemes that
hav ebeen described which *require* the guest to somehow indicate the
page is in use before starting to use the page again.

Dave

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [e-mail]
> For additional commands, e-mail: [e-mail]
> 
--
Dr. David Alan Gilbert / [e-mail] / Manchester, UK

David Hildenbrand Sept. 10, 2019, 4:22 p.m. UTC | #7

On 10.09.19 18:18, Dr. David Alan Gilbert wrote:
> * Alexander Duyck ([e-mail]) wrote:
>> On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <[e-mail]> wrote:
>>>
>>> On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
>>>> On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <[e-mail]> wrote:
>>>>>
>>>>> I wanted to review "mm: Introduce Reported pages" just realize that I
>>>>> have no clue on what is going on so returned to the cover and it didn't
>>>>> really help much. I am completely unfamiliar with virtio so please bear
>>>>> with me.
>>>>>
>>>>> On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
>>>>> [...]
>>>>>> This series provides an asynchronous means of reporting to a hypervisor
>>>>>> that a guest page is no longer in use and can have the data associated
>>>>>> with it dropped. To do this I have implemented functionality that allows
>>>>>> for what I am referring to as unused page reporting
>>>>>>
>>>>>> The functionality for this is fairly simple. When enabled it will allocate
>>>>>> statistics to track the number of reported pages in a given free area.
>>>>>> When the number of free pages exceeds this value plus a high water value,
>>>>>> currently 32, it will begin performing page reporting which consists of
>>>>>> pulling pages off of free list and placing them into a scatter list. The
>>>>>> scatterlist is then given to the page reporting device and it will perform
>>>>>> the required action to make the pages "reported", in the case of
>>>>>> virtio-balloon this results in the pages being madvised as MADV_DONTNEED
>>>>>> and as such they are forced out of the guest. After this they are placed
>>>>>> back on the free list,
>>>>>
>>>>> And here I am reallly lost because "forced out of the guest" makes me
>>>>> feel that those pages are no longer usable by the guest. So how come you
>>>>> can add them back to the free list. I suspect understanding this part
>>>>> will allow me to understand why we have to mark those pages and prevent
>>>>> merging.
>>>>
>>>> Basically as the paragraph above mentions "forced out of the guest"
>>>> really is just the hypervisor calling MADV_DONTNEED on the page in
>>>> question. So the behavior is the same as any userspace application
>>>> that calls MADV_DONTNEED where the contents are no longer accessible
>>>> from userspace and attempting to access them will result in a fault
>>>> and the page being populated with a zero fill on-demand page, or a
>>>> copy of the file contents if the memory is file backed.
>>>
>>> As I've said I have no idea about virt so this doesn't really tell me
>>> much. Does that mean that if somebody allocates such a page and tries to
>>> access it then virt will handle a fault and bring it back?
>>
>> Actually I am probably describing too much as the MADV_DONTNEED is the
>> hypervisor behavior in response to the virtio-balloon notification. A
>> more thorough explanation of it can be found by just running "man
>> madvise", probably best just to leave it at that since I am probably
>> confusing things by describing hypervisor behavior in a kernel patch
>> set.
>>
>> For the most part all the page reporting really does is provide a way
>> to incrementally identify unused regions of memory in the buddy
>> allocator. That in turn is used by virtio-balloon in a polling thread
>> to report to the hypervisor what pages are not in use so that it can
>> make a decision on what to do with the pages now that it knows they
>> are unused.
>>
>> All this is providing is just a report and it is optional if the
>> hypervisor will act on it or not. If the hypervisor takes some sort of
>> action on the page, then the expectation is that the hypervisor will
>> use some sort of mechanism such as a page fault to discover when the
>> page is used again.
> 
> OK, that's interestingly different (but OK) from some other schemes that
> hav ebeen described which *require* the guest to somehow indicate the
> page is in use before starting to use the page again.
> 

virtio-balloon also has a mode where the guest would not have to
indicate to the host before re-using a page. Only
VIRTIO_BALLOON_F_MUST_TELL_HOST enforces this. So it's not completely new.

> Dave

Michal Hocko Sept. 10, 2019, 5:52 p.m. UTC | #8

On Tue 10-09-19 09:05:43, Alexander Duyck wrote:
> On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <[e-mail]> wrote:
> >
> > On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> > > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <[e-mail]> wrote:
> > > >
> > > > I wanted to review "mm: Introduce Reported pages" just realize that I
> > > > have no clue on what is going on so returned to the cover and it didn't
> > > > really help much. I am completely unfamiliar with virtio so please bear
> > > > with me.
> > > >
> > > > On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> > > > [...]
> > > > > This series provides an asynchronous means of reporting to a hypervisor
> > > > > that a guest page is no longer in use and can have the data associated
> > > > > with it dropped. To do this I have implemented functionality that allows
> > > > > for what I am referring to as unused page reporting
> > > > >
> > > > > The functionality for this is fairly simple. When enabled it will allocate
> > > > > statistics to track the number of reported pages in a given free area.
> > > > > When the number of free pages exceeds this value plus a high water value,
> > > > > currently 32, it will begin performing page reporting which consists of
> > > > > pulling pages off of free list and placing them into a scatter list. The
> > > > > scatterlist is then given to the page reporting device and it will perform
> > > > > the required action to make the pages "reported", in the case of
> > > > > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > > > > and as such they are forced out of the guest. After this they are placed
> > > > > back on the free list,
> > > >
> > > > And here I am reallly lost because "forced out of the guest" makes me
> > > > feel that those pages are no longer usable by the guest. So how come you
> > > > can add them back to the free list. I suspect understanding this part
> > > > will allow me to understand why we have to mark those pages and prevent
> > > > merging.
> > >
> > > Basically as the paragraph above mentions "forced out of the guest"
> > > really is just the hypervisor calling MADV_DONTNEED on the page in
> > > question. So the behavior is the same as any userspace application
> > > that calls MADV_DONTNEED where the contents are no longer accessible
> > > from userspace and attempting to access them will result in a fault
> > > and the page being populated with a zero fill on-demand page, or a
> > > copy of the file contents if the memory is file backed.
> >
> > As I've said I have no idea about virt so this doesn't really tell me
> > much. Does that mean that if somebody allocates such a page and tries to
> > access it then virt will handle a fault and bring it back?
> 
> Actually I am probably describing too much as the MADV_DONTNEED is the
> hypervisor behavior in response to the virtio-balloon notification. A
> more thorough explanation of it can be found by just running "man
> madvise", probably best just to leave it at that since I am probably
> confusing things by describing hypervisor behavior in a kernel patch
> set.

This analogy is indeed confusing and doesn't help to build a picture.

> For the most part all the page reporting really does is provide a way
> to incrementally identify unused regions of memory in the buddy
> allocator. That in turn is used by virtio-balloon in a polling thread
> to report to the hypervisor what pages are not in use so that it can
> make a decision on what to do with the pages now that it knows they
> are unused.

So essentially you want to store metadata into free pages and control
what the allocator can do with them? Namely buddy merging if the type
doesn't match?

> All this is providing is just a report and it is optional if the
> hypervisor will act on it or not. If the hypervisor takes some sort of
> action on the page, then the expectation is that the hypervisor will
> use some sort of mechanism such as a page fault to discover when the
> page is used again.

OK so the baloon driver is in charge of this metadata and the allocator
has to live with that. Isn't that a layer violation?

Michal Hocko Sept. 10, 2019, 6 p.m. UTC | #9

On Tue 10-09-19 19:52:13, Michal Hocko wrote:
> On Tue 10-09-19 09:05:43, Alexander Duyck wrote:
[...]
> > All this is providing is just a report and it is optional if the
> > hypervisor will act on it or not. If the hypervisor takes some sort of
> > action on the page, then the expectation is that the hypervisor will
> > use some sort of mechanism such as a page fault to discover when the
> > page is used again.
> 
> OK so the baloon driver is in charge of this metadata and the allocator
> has to live with that. Isn't that a layer violation?

Another thing that is not clear to me is how these marked pages are
different from any other free pages. All of them are unused and you are
losing your metadata as soon as the page gets allocated because the page
changes its owner and the struct page belongs to it.

Alexander Duyck Sept. 10, 2019, 8:37 p.m. UTC | #10

On Tue, 2019-09-10 at 20:00 +0200, Michal Hocko wrote:
> On Tue 10-09-19 19:52:13, Michal Hocko wrote:
> > On Tue 10-09-19 09:05:43, Alexander Duyck wrote:
> [...]
> > > All this is providing is just a report and it is optional if the
> > > hypervisor will act on it or not. If the hypervisor takes some sort of
> > > action on the page, then the expectation is that the hypervisor will
> > > use some sort of mechanism such as a page fault to discover when the
> > > page is used again.
> > 
> > OK so the baloon driver is in charge of this metadata and the allocator
> > has to live with that. Isn't that a layer violation?
> 
> Another thing that is not clear to me is how these marked pages are
> different from any other free pages. All of them are unused and you are
> losing your metadata as soon as the page gets allocated because the page
> changes its owner and the struct page belongs to it.

Really they aren't any different then other free pages other than they are
marked. Us losing the metadata as soon as the page is allocated is fine as
we will need to re-report it when it is returned so we no longer need the
metadata once it is allocated.

Alexander Duyck Sept. 10, 2019, 9:23 p.m. UTC | #11

On Tue, 2019-09-10 at 19:52 +0200, Michal Hocko wrote:
> On Tue 10-09-19 09:05:43, Alexander Duyck wrote:
> > On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <[e-mail]> wrote:
> > > On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> > > > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <[e-mail]> wrote:
> > > > > I wanted to review "mm: Introduce Reported pages" just realize that I
> > > > > have no clue on what is going on so returned to the cover and it didn't
> > > > > really help much. I am completely unfamiliar with virtio so please bear
> > > > > with me.
> > > > > 
> > > > > On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> > > > > [...]
> > > > > > This series provides an asynchronous means of reporting to a hypervisor
> > > > > > that a guest page is no longer in use and can have the data associated
> > > > > > with it dropped. To do this I have implemented functionality that allows
> > > > > > for what I am referring to as unused page reporting
> > > > > > 
> > > > > > The functionality for this is fairly simple. When enabled it will allocate
> > > > > > statistics to track the number of reported pages in a given free area.
> > > > > > When the number of free pages exceeds this value plus a high water value,
> > > > > > currently 32, it will begin performing page reporting which consists of
> > > > > > pulling pages off of free list and placing them into a scatter list. The
> > > > > > scatterlist is then given to the page reporting device and it will perform
> > > > > > the required action to make the pages "reported", in the case of
> > > > > > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > > > > > and as such they are forced out of the guest. After this they are placed
> > > > > > back on the free list,
> > > > > 
> > > > > And here I am reallly lost because "forced out of the guest" makes me
> > > > > feel that those pages are no longer usable by the guest. So how come you
> > > > > can add them back to the free list. I suspect understanding this part
> > > > > will allow me to understand why we have to mark those pages and prevent
> > > > > merging.
> > > > 
> > > > Basically as the paragraph above mentions "forced out of the guest"
> > > > really is just the hypervisor calling MADV_DONTNEED on the page in
> > > > question. So the behavior is the same as any userspace application
> > > > that calls MADV_DONTNEED where the contents are no longer accessible
> > > > from userspace and attempting to access them will result in a fault
> > > > and the page being populated with a zero fill on-demand page, or a
> > > > copy of the file contents if the memory is file backed.
> > > 
> > > As I've said I have no idea about virt so this doesn't really tell me
> > > much. Does that mean that if somebody allocates such a page and tries to
> > > access it then virt will handle a fault and bring it back?
> > 
> > Actually I am probably describing too much as the MADV_DONTNEED is the
> > hypervisor behavior in response to the virtio-balloon notification. A
> > more thorough explanation of it can be found by just running "man
> > madvise", probably best just to leave it at that since I am probably
> > confusing things by describing hypervisor behavior in a kernel patch
> > set.
> 
> This analogy is indeed confusing and doesn't help to build a picture.

All I am really doing is using a pointer per free_list, the page->index, 
and a page flag to provide a way to iterate over the list in such a way
that I will not repeat the operation on a page I have already reported. It
is taking advantage of the fact that we add pages to either the head or
the tail of the list, and can pull the pages from anywhere in the list, so
we have to work around those edges to avoid processing the already
reported pages in between.

Admittedly this is pretty complex. I've been at this for several months,
and have gone through several iterations.

If it helps I can try to draw it out as a bit of ASCII art. Basically what
I am trying to do is find a way to skip over the blob of reported pages
that would exist after we have not been reporting for a little while. Most
of this logic is in the get_reported_pages/free_reported_pages that should
be in patch 6.

So on our first iteration through the pages it is pretty straightforward.
We basically just keep pushing the boundary pointer up, we fetch the pages
immediately in front of it, and then when we return the now-reported pages
we push the boundary pointer up to those pages.

While we are actively reporting a given zone we prevent any pages from
being inserted behind the boundary. They are always inserted before the
boundary pointer. This is achieved by replacing the free_list tail pointer
value with the boundary pointer value in the case of add_to_tail calls.

Legend:
U Unused Page
R Reported Page
< Boundary Reported Page

     Head ....................................................... Tail
Start     UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU <
..        UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU<RRRRRRRRRRRRRRRRRRRRRRR
End       UU<RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR

After we completed the boundary pointer is discarded and we don't have to
update it when the zone->flag indicating reporting is active is no longer
set. What we then have happening is that pages are pulled out of the
free_list at random locations or from the head. This causes the list of
reported pages to slowly shrink, however the block of pages should remain
contiguous since new pages are only added to the head or the tail.

     Head ....................................................... Tail
Idle      UUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRUUUU

Once we have a large enough difference between the nr_free and
reported_pages we will then restart the reporting by resetting the
boundary to the tail and proceeding to pull the non-reported pages that
are in front of the boundary(fig1). Once those are exhasusted we will
start pulling the pages from the head of the list, reporting those, and
then placing them back at the boundary(fig2). When we finally hit the
point where there are no more pages to pull from the head that are not
reported we will update the boundary to the first reported page in the
list, return the reported pages there, and we should be done reporting
pages from this free list.

     Head ....................................................... Tail
Start     UUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRUUUU <
fig1      UUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRU<RRRR
fig2      UUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR<RRRRRRRRRRRRRRRRRRRR
End       UU<RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR

The goal with all this is to allow the boundary pointer to move, but to
guarantee forward progress as we work our way through the free_list(s).
Essentially the only requirements we are posing on the page allocator is
that if it pulls the page at the boundary it has to push it back, and if
it wants to add to the tail it has to use the boundary page as the tail
instead.

> > For the most part all the page reporting really does is provide a way
> > to incrementally identify unused regions of memory in the buddy
> > allocator. That in turn is used by virtio-balloon in a polling thread
> > to report to the hypervisor what pages are not in use so that it can
> > make a decision on what to do with the pages now that it knows they
> > are unused.
> 
> So essentially you want to store metadata into free pages and control
> what the allocator can do with them? Namely buddy merging if the type
> doesn't match?

We don't put any limitations on the allocator other then that it needs to
clean up the metadata on allocation, and that it cannot allocate a page
that is in the process of being reported since we pulled it from the
free_list. If the page is a "Reported" page then it decrements the
reported_pages count for the free_area and makes sure the page doesn't
exist in the "Boundary" array pointer value, if it does it moves the
"Boundary" since it is pulling the page.

> > All this is providing is just a report and it is optional if the
> > hypervisor will act on it or not. If the hypervisor takes some sort of
> > action on the page, then the expectation is that the hypervisor will
> > use some sort of mechanism such as a page fault to discover when the
> > page is used again.
> 
> OK so the baloon driver is in charge of this metadata and the allocator
> has to live with that. Isn't that a layer violation?

Really the metadata belongs to the page reporting. The virtio balloon
driver doesn't get to see any of it. It basically registers as a Reporting
interface and then we start sending it scatterlists to report. It doesn't
do anything with the actual pages themselves other then DMA map the
physical addresses for them.

Michael S. Tsirkin Sept. 11, 2019, 9:23 a.m. UTC | #12

On Tue, Sep 10, 2019 at 06:22:37PM +0200, David Hildenbrand wrote:
> On 10.09.19 18:18, Dr. David Alan Gilbert wrote:
> > * Alexander Duyck ([e-mail]) wrote:
> >> On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <[e-mail]> wrote:
> >>>
> >>> On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> >>>> On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <[e-mail]> wrote:
> >>>>>
> >>>>> I wanted to review "mm: Introduce Reported pages" just realize that I
> >>>>> have no clue on what is going on so returned to the cover and it didn't
> >>>>> really help much. I am completely unfamiliar with virtio so please bear
> >>>>> with me.
> >>>>>
> >>>>> On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> >>>>> [...]
> >>>>>> This series provides an asynchronous means of reporting to a hypervisor
> >>>>>> that a guest page is no longer in use and can have the data associated
> >>>>>> with it dropped. To do this I have implemented functionality that allows
> >>>>>> for what I am referring to as unused page reporting
> >>>>>>
> >>>>>> The functionality for this is fairly simple. When enabled it will allocate
> >>>>>> statistics to track the number of reported pages in a given free area.
> >>>>>> When the number of free pages exceeds this value plus a high water value,
> >>>>>> currently 32, it will begin performing page reporting which consists of
> >>>>>> pulling pages off of free list and placing them into a scatter list. The
> >>>>>> scatterlist is then given to the page reporting device and it will perform
> >>>>>> the required action to make the pages "reported", in the case of
> >>>>>> virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> >>>>>> and as such they are forced out of the guest. After this they are placed
> >>>>>> back on the free list,
> >>>>>
> >>>>> And here I am reallly lost because "forced out of the guest" makes me
> >>>>> feel that those pages are no longer usable by the guest. So how come you
> >>>>> can add them back to the free list. I suspect understanding this part
> >>>>> will allow me to understand why we have to mark those pages and prevent
> >>>>> merging.
> >>>>
> >>>> Basically as the paragraph above mentions "forced out of the guest"
> >>>> really is just the hypervisor calling MADV_DONTNEED on the page in
> >>>> question. So the behavior is the same as any userspace application
> >>>> that calls MADV_DONTNEED where the contents are no longer accessible
> >>>> from userspace and attempting to access them will result in a fault
> >>>> and the page being populated with a zero fill on-demand page, or a
> >>>> copy of the file contents if the memory is file backed.
> >>>
> >>> As I've said I have no idea about virt so this doesn't really tell me
> >>> much. Does that mean that if somebody allocates such a page and tries to
> >>> access it then virt will handle a fault and bring it back?
> >>
> >> Actually I am probably describing too much as the MADV_DONTNEED is the
> >> hypervisor behavior in response to the virtio-balloon notification. A
> >> more thorough explanation of it can be found by just running "man
> >> madvise", probably best just to leave it at that since I am probably
> >> confusing things by describing hypervisor behavior in a kernel patch
> >> set.
> >>
> >> For the most part all the page reporting really does is provide a way
> >> to incrementally identify unused regions of memory in the buddy
> >> allocator. That in turn is used by virtio-balloon in a polling thread
> >> to report to the hypervisor what pages are not in use so that it can
> >> make a decision on what to do with the pages now that it knows they
> >> are unused.
> >>
> >> All this is providing is just a report and it is optional if the
> >> hypervisor will act on it or not. If the hypervisor takes some sort of
> >> action on the page, then the expectation is that the hypervisor will
> >> use some sort of mechanism such as a page fault to discover when the
> >> page is used again.
> > 
> > OK, that's interestingly different (but OK) from some other schemes that
> > hav ebeen described which *require* the guest to somehow indicate the
> > page is in use before starting to use the page again.
> > 
> 
> virtio-balloon also has a mode where the guest would not have to
> indicate to the host before re-using a page. Only
> VIRTIO_BALLOON_F_MUST_TELL_HOST enforces this. So it's not completely new.

VIRTIO_BALLOON_F_MUST_TELL_HOST is a bit different.
When it's not set, guest still must tell host about
pages in use, it just can batch these notifications
sending them possibly after page has been used.
So even with VIRTIO_BALLOON_F_MUST_TELL_HOST off you don't
skip the notification.


From hypervisor point of view, this feature is very much like adding
page to the balloon and immediately taking it out of the balloon again,
just doing it in one operation.

The main difference is the contents of the page, which matters
with poisoning: in that case hypervisor is expected to hand
back page with the poisoning content. Not so with regular
deflate where page contents is undefined.

Well and also the new interface is optimized for large chunks
of memory since we'll likely be dealing with such.

> > Dave
> 
> 
> -- 
> 
> Thanks,
> 
> David / dhildenb

David Hildenbrand Sept. 11, 2019, 9:50 a.m. UTC | #13

On 11.09.19 11:23, Michael S. Tsirkin wrote:
> On Tue, Sep 10, 2019 at 06:22:37PM +0200, David Hildenbrand wrote:
>> On 10.09.19 18:18, Dr. David Alan Gilbert wrote:
>>> * Alexander Duyck ([e-mail]) wrote:
>>>> On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <[e-mail]> wrote:
>>>>>
>>>>> On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
>>>>>> On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <[e-mail]> wrote:
>>>>>>>
>>>>>>> I wanted to review "mm: Introduce Reported pages" just realize that I
>>>>>>> have no clue on what is going on so returned to the cover and it didn't
>>>>>>> really help much. I am completely unfamiliar with virtio so please bear
>>>>>>> with me.
>>>>>>>
>>>>>>> On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
>>>>>>> [...]
>>>>>>>> This series provides an asynchronous means of reporting to a hypervisor
>>>>>>>> that a guest page is no longer in use and can have the data associated
>>>>>>>> with it dropped. To do this I have implemented functionality that allows
>>>>>>>> for what I am referring to as unused page reporting
>>>>>>>>
>>>>>>>> The functionality for this is fairly simple. When enabled it will allocate
>>>>>>>> statistics to track the number of reported pages in a given free area.
>>>>>>>> When the number of free pages exceeds this value plus a high water value,
>>>>>>>> currently 32, it will begin performing page reporting which consists of
>>>>>>>> pulling pages off of free list and placing them into a scatter list. The
>>>>>>>> scatterlist is then given to the page reporting device and it will perform
>>>>>>>> the required action to make the pages "reported", in the case of
>>>>>>>> virtio-balloon this results in the pages being madvised as MADV_DONTNEED
>>>>>>>> and as such they are forced out of the guest. After this they are placed
>>>>>>>> back on the free list,
>>>>>>>
>>>>>>> And here I am reallly lost because "forced out of the guest" makes me
>>>>>>> feel that those pages are no longer usable by the guest. So how come you
>>>>>>> can add them back to the free list. I suspect understanding this part
>>>>>>> will allow me to understand why we have to mark those pages and prevent
>>>>>>> merging.
>>>>>>
>>>>>> Basically as the paragraph above mentions "forced out of the guest"
>>>>>> really is just the hypervisor calling MADV_DONTNEED on the page in
>>>>>> question. So the behavior is the same as any userspace application
>>>>>> that calls MADV_DONTNEED where the contents are no longer accessible
>>>>>> from userspace and attempting to access them will result in a fault
>>>>>> and the page being populated with a zero fill on-demand page, or a
>>>>>> copy of the file contents if the memory is file backed.
>>>>>
>>>>> As I've said I have no idea about virt so this doesn't really tell me
>>>>> much. Does that mean that if somebody allocates such a page and tries to
>>>>> access it then virt will handle a fault and bring it back?
>>>>
>>>> Actually I am probably describing too much as the MADV_DONTNEED is the
>>>> hypervisor behavior in response to the virtio-balloon notification. A
>>>> more thorough explanation of it can be found by just running "man
>>>> madvise", probably best just to leave it at that since I am probably
>>>> confusing things by describing hypervisor behavior in a kernel patch
>>>> set.
>>>>
>>>> For the most part all the page reporting really does is provide a way
>>>> to incrementally identify unused regions of memory in the buddy
>>>> allocator. That in turn is used by virtio-balloon in a polling thread
>>>> to report to the hypervisor what pages are not in use so that it can
>>>> make a decision on what to do with the pages now that it knows they
>>>> are unused.
>>>>
>>>> All this is providing is just a report and it is optional if the
>>>> hypervisor will act on it or not. If the hypervisor takes some sort of
>>>> action on the page, then the expectation is that the hypervisor will
>>>> use some sort of mechanism such as a page fault to discover when the
>>>> page is used again.
>>>
>>> OK, that's interestingly different (but OK) from some other schemes that
>>> hav ebeen described which *require* the guest to somehow indicate the
>>> page is in use before starting to use the page again.
>>>
>>
>> virtio-balloon also has a mode where the guest would not have to
>> indicate to the host before re-using a page. Only
>> VIRTIO_BALLOON_F_MUST_TELL_HOST enforces this. So it's not completely new.
> 
> VIRTIO_BALLOON_F_MUST_TELL_HOST is a bit different.
> When it's not set, guest still must tell host about
> pages in use, it just can batch these notifications
> sending them possibly after page has been used.
> So even with VIRTIO_BALLOON_F_MUST_TELL_HOST off you don't
> skip the notification.
> 

I don't think so

VIRTIO_BALLOON_F_MUST_TELL_HOST     0 /* Tell before reclaiming pages */

commit bf50e69f63d21091e525185c3ae761412be0ba72
Author: Dave Hansen <[e-mail]>
Date:   Thu Apr 7 10:43:25 2011 -0700

    virtio balloon: kill tell-host-first logic

[...]

    But, if the bit is _not_ set, we are under no obligation to
    reverse the order; we're under no obligation to do _anything_.
    As of now, qemu-kvm defines the bit, but doesn't set it.


Old code simply told the hypervisor afterwards, but only for little
performance gain. It is not strictly necessary.

> From hypervisor point of view, this feature is very much like adding
> page to the balloon and immediately taking it out of the balloon again,
> just doing it in one operation.
> 
> The main difference is the contents of the page, which matters
> with poisoning: in that case hypervisor is expected to hand
> back page with the poisoning content. Not so with regular
> deflate where page contents is undefined.
> 
> Well and also the new interface is optimized for large chunks
> of memory since we'll likely be dealing with such.
> 
>>> Dave
>>
>>
>> -- 
>>
>> Thanks,
>>
>> David / dhildenb

Michal Hocko Sept. 11, 2019, 11:36 a.m. UTC | #14

On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
[...]
> We don't put any limitations on the allocator other then that it needs to
> clean up the metadata on allocation, and that it cannot allocate a page
> that is in the process of being reported since we pulled it from the
> free_list. If the page is a "Reported" page then it decrements the
> reported_pages count for the free_area and makes sure the page doesn't
> exist in the "Boundary" array pointer value, if it does it moves the
> "Boundary" since it is pulling the page.

This is still a non-trivial limitation on the page allocation from an
external code IMHO. I cannot give any explicit reason why an ordering on
the free list might matter (well except for page shuffling which uses it
to make physical memory pattern allocation more random) but the
architecture seems hacky and dubious to be honest. It shoulds like the
whole interface has been developed around a very particular and single
purpose optimization.

I remember that there was an attempt to report free memory that provided
a callback mechanism [1], which was much less intrusive to the internals
of the allocator yet it should provide a similar functionality. Did you
see that approach? How does this compares to it? Or am I completely off
when comparing them?

[1] mostly likely not the latest version of the patchset
http://lkml.kernel.org/r/[e-mail]

David Hildenbrand Sept. 11, 2019, 11:47 a.m. UTC | #15

On 11.09.19 13:36, Michal Hocko wrote:
> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> [...]
>> We don't put any limitations on the allocator other then that it needs to
>> clean up the metadata on allocation, and that it cannot allocate a page
>> that is in the process of being reported since we pulled it from the
>> free_list. If the page is a "Reported" page then it decrements the
>> reported_pages count for the free_area and makes sure the page doesn't
>> exist in the "Boundary" array pointer value, if it does it moves the
>> "Boundary" since it is pulling the page.
> 
> This is still a non-trivial limitation on the page allocation from an
> external code IMHO. I cannot give any explicit reason why an ordering on
> the free list might matter (well except for page shuffling which uses it
> to make physical memory pattern allocation more random) but the
> architecture seems hacky and dubious to be honest. It shoulds like the
> whole interface has been developed around a very particular and single
> purpose optimization.
> 
> I remember that there was an attempt to report free memory that provided
> a callback mechanism [1], which was much less intrusive to the internals
> of the allocator yet it should provide a similar functionality. Did you
> see that approach? How does this compares to it? Or am I completely off
> when comparing them?
> 
> [1] mostly likely not the latest version of the patchset
> http://lkml.kernel.org/r/[e-mail]
> 

FWIW, Nitesh was looking into another approach [1], whereby the metadata
is stored outside of the buddy (unreported pages are tracked in a
bitmap). There are some limitations to this approach (esp., sparse zones
might waste memory (1bit per 2MB), memory hot(un)plug not supported yet
completely, scanning of the bitmap necessary). OTOH, the core buddy
modifications are minimized.

[1] https://lkml.org/lkml/2019/8/12/593

Michael S. Tsirkin Sept. 11, 2019, 12:08 p.m. UTC | #16

On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> [...]
> > We don't put any limitations on the allocator other then that it needs to
> > clean up the metadata on allocation, and that it cannot allocate a page
> > that is in the process of being reported since we pulled it from the
> > free_list. If the page is a "Reported" page then it decrements the
> > reported_pages count for the free_area and makes sure the page doesn't
> > exist in the "Boundary" array pointer value, if it does it moves the
> > "Boundary" since it is pulling the page.
> 
> This is still a non-trivial limitation on the page allocation from an
> external code IMHO. I cannot give any explicit reason why an ordering on
> the free list might matter (well except for page shuffling which uses it
> to make physical memory pattern allocation more random) but the
> architecture seems hacky and dubious to be honest. It shoulds like the
> whole interface has been developed around a very particular and single
> purpose optimization.
> 
> I remember that there was an attempt to report free memory that provided
> a callback mechanism [1], which was much less intrusive to the internals
> of the allocator yet it should provide a similar functionality. Did you
> see that approach? How does this compares to it? Or am I completely off
> when comparing them?
> 
> [1] mostly likely not the latest version of the patchset
> http://lkml.kernel.org/r/[e-mail]
> 
> -- 
> Michal Hocko
> SUSE Labs

Linus nacked that one. He thinks invoking callbacks with lots of
internal mm locks is too fragile.

Michal Hocko Sept. 11, 2019, 12:19 p.m. UTC | #17

On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
> > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > [...]
> > > We don't put any limitations on the allocator other then that it needs to
> > > clean up the metadata on allocation, and that it cannot allocate a page
> > > that is in the process of being reported since we pulled it from the
> > > free_list. If the page is a "Reported" page then it decrements the
> > > reported_pages count for the free_area and makes sure the page doesn't
> > > exist in the "Boundary" array pointer value, if it does it moves the
> > > "Boundary" since it is pulling the page.
> > 
> > This is still a non-trivial limitation on the page allocation from an
> > external code IMHO. I cannot give any explicit reason why an ordering on
> > the free list might matter (well except for page shuffling which uses it
> > to make physical memory pattern allocation more random) but the
> > architecture seems hacky and dubious to be honest. It shoulds like the
> > whole interface has been developed around a very particular and single
> > purpose optimization.
> > 
> > I remember that there was an attempt to report free memory that provided
> > a callback mechanism [1], which was much less intrusive to the internals
> > of the allocator yet it should provide a similar functionality. Did you
> > see that approach? How does this compares to it? Or am I completely off
> > when comparing them?
> > 
> > [1] mostly likely not the latest version of the patchset
> > http://lkml.kernel.org/r/[e-mail]
> 
> Linus nacked that one. He thinks invoking callbacks with lots of
> internal mm locks is too fragile.

I would be really curious how much he would be happy about injecting
other restrictions on the allocator like this patch proposes. This is
more intrusive as it has a higher maintenance cost longterm IMHO.

Michal Hocko Sept. 11, 2019, 12:25 p.m. UTC | #18

On Wed 11-09-19 14:19:41, Michal Hocko wrote:
> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
> > On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
> > > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > > [...]
> > > > We don't put any limitations on the allocator other then that it needs to
> > > > clean up the metadata on allocation, and that it cannot allocate a page
> > > > that is in the process of being reported since we pulled it from the
> > > > free_list. If the page is a "Reported" page then it decrements the
> > > > reported_pages count for the free_area and makes sure the page doesn't
> > > > exist in the "Boundary" array pointer value, if it does it moves the
> > > > "Boundary" since it is pulling the page.
> > > 
> > > This is still a non-trivial limitation on the page allocation from an
> > > external code IMHO. I cannot give any explicit reason why an ordering on
> > > the free list might matter (well except for page shuffling which uses it
> > > to make physical memory pattern allocation more random) but the
> > > architecture seems hacky and dubious to be honest. It shoulds like the
> > > whole interface has been developed around a very particular and single
> > > purpose optimization.
> > > 
> > > I remember that there was an attempt to report free memory that provided
> > > a callback mechanism [1], which was much less intrusive to the internals
> > > of the allocator yet it should provide a similar functionality. Did you
> > > see that approach? How does this compares to it? Or am I completely off
> > > when comparing them?
> > > 
> > > [1] mostly likely not the latest version of the patchset
> > > http://lkml.kernel.org/r/[e-mail]
> > 
> > Linus nacked that one. He thinks invoking callbacks with lots of
> > internal mm locks is too fragile.
> 
> I would be really curious how much he would be happy about injecting
> other restrictions on the allocator like this patch proposes. This is
> more intrusive as it has a higher maintenance cost longterm IMHO.

Btw. I do agree that callbacks with internal mm locks are not great
either. We do have a model for that in mmu_notifiers and it is something
I do consider PITA, on the other hand it is mostly sleepable part of the
interface which makes it the real pain. The above callback mechanism was
explicitly documented with restrictions and that the context is
essentially atomic with no access to particular struct pages and no
expensive operations possible. So in the end I've considered it
acceptably painful. Not that I want to override Linus' nack but if
virtualization usecases really require some form of reporting and no
other way to do that push people to invent even more interesting
approaches then we should simply give them/you something reasonable
and least intrusive to our internals.

David Hildenbrand Sept. 11, 2019, 12:42 p.m. UTC | #19

On 11.09.19 14:25, Michal Hocko wrote:
> On Wed 11-09-19 14:19:41, Michal Hocko wrote:
>> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
>>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
>>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
>>>> [...]
>>>>> We don't put any limitations on the allocator other then that it needs to
>>>>> clean up the metadata on allocation, and that it cannot allocate a page
>>>>> that is in the process of being reported since we pulled it from the
>>>>> free_list. If the page is a "Reported" page then it decrements the
>>>>> reported_pages count for the free_area and makes sure the page doesn't
>>>>> exist in the "Boundary" array pointer value, if it does it moves the
>>>>> "Boundary" since it is pulling the page.
>>>>
>>>> This is still a non-trivial limitation on the page allocation from an
>>>> external code IMHO. I cannot give any explicit reason why an ordering on
>>>> the free list might matter (well except for page shuffling which uses it
>>>> to make physical memory pattern allocation more random) but the
>>>> architecture seems hacky and dubious to be honest. It shoulds like the
>>>> whole interface has been developed around a very particular and single
>>>> purpose optimization.
>>>>
>>>> I remember that there was an attempt to report free memory that provided
>>>> a callback mechanism [1], which was much less intrusive to the internals
>>>> of the allocator yet it should provide a similar functionality. Did you
>>>> see that approach? How does this compares to it? Or am I completely off
>>>> when comparing them?
>>>>
>>>> [1] mostly likely not the latest version of the patchset
>>>> http://lkml.kernel.org/r/[e-mail]
>>>
>>> Linus nacked that one. He thinks invoking callbacks with lots of
>>> internal mm locks is too fragile.
>>
>> I would be really curious how much he would be happy about injecting
>> other restrictions on the allocator like this patch proposes. This is
>> more intrusive as it has a higher maintenance cost longterm IMHO.
> 
> Btw. I do agree that callbacks with internal mm locks are not great
> either. We do have a model for that in mmu_notifiers and it is something
> I do consider PITA, on the other hand it is mostly sleepable part of the
> interface which makes it the real pain. The above callback mechanism was
> explicitly documented with restrictions and that the context is
> essentially atomic with no access to particular struct pages and no
> expensive operations possible. So in the end I've considered it
> acceptably painful. Not that I want to override Linus' nack but if
> virtualization usecases really require some form of reporting and no
> other way to do that push people to invent even more interesting
> approaches then we should simply give them/you something reasonable
> and least intrusive to our internals.
> 

The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
 is that it cannot really handle the use case we have here if I am not
wrong. While a page is getting processed by the hypervisor (e.g.
MADV_DONTNEED), it must not get reused.

"Some page blocks may
leave the free list after zone->lock is released, so it is the caller's
responsibility to either detect or prevent the use of such pages."

If I'm not wrong, this only made sense to speed up migration in the
hypervisor, where you can deal with false positives differently.

Michal Hocko Sept. 11, 2019, 12:54 p.m. UTC | #20

On Wed 11-09-19 14:42:41, David Hildenbrand wrote:
> On 11.09.19 14:25, Michal Hocko wrote:
> > On Wed 11-09-19 14:19:41, Michal Hocko wrote:
> >> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
> >>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
> >>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> >>>> [...]
> >>>>> We don't put any limitations on the allocator other then that it needs to
> >>>>> clean up the metadata on allocation, and that it cannot allocate a page
> >>>>> that is in the process of being reported since we pulled it from the
> >>>>> free_list. If the page is a "Reported" page then it decrements the
> >>>>> reported_pages count for the free_area and makes sure the page doesn't
> >>>>> exist in the "Boundary" array pointer value, if it does it moves the
> >>>>> "Boundary" since it is pulling the page.
> >>>>
> >>>> This is still a non-trivial limitation on the page allocation from an
> >>>> external code IMHO. I cannot give any explicit reason why an ordering on
> >>>> the free list might matter (well except for page shuffling which uses it
> >>>> to make physical memory pattern allocation more random) but the
> >>>> architecture seems hacky and dubious to be honest. It shoulds like the
> >>>> whole interface has been developed around a very particular and single
> >>>> purpose optimization.
> >>>>
> >>>> I remember that there was an attempt to report free memory that provided
> >>>> a callback mechanism [1], which was much less intrusive to the internals
> >>>> of the allocator yet it should provide a similar functionality. Did you
> >>>> see that approach? How does this compares to it? Or am I completely off
> >>>> when comparing them?
> >>>>
> >>>> [1] mostly likely not the latest version of the patchset
> >>>> http://lkml.kernel.org/r/[e-mail]
> >>>
> >>> Linus nacked that one. He thinks invoking callbacks with lots of
> >>> internal mm locks is too fragile.
> >>
> >> I would be really curious how much he would be happy about injecting
> >> other restrictions on the allocator like this patch proposes. This is
> >> more intrusive as it has a higher maintenance cost longterm IMHO.
> > 
> > Btw. I do agree that callbacks with internal mm locks are not great
> > either. We do have a model for that in mmu_notifiers and it is something
> > I do consider PITA, on the other hand it is mostly sleepable part of the
> > interface which makes it the real pain. The above callback mechanism was
> > explicitly documented with restrictions and that the context is
> > essentially atomic with no access to particular struct pages and no
> > expensive operations possible. So in the end I've considered it
> > acceptably painful. Not that I want to override Linus' nack but if
> > virtualization usecases really require some form of reporting and no
> > other way to do that push people to invent even more interesting
> > approaches then we should simply give them/you something reasonable
> > and least intrusive to our internals.
> > 
> 
> The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
>  is that it cannot really handle the use case we have here if I am not
> wrong. While a page is getting processed by the hypervisor (e.g.
> MADV_DONTNEED), it must not get reused.

What prevents to use the callback to get a list of pfn ranges to work on
and then use something like start_isolate_page_range on the collected
pfn ranges to make sure nobody steals pages from under your feet, do
your thing and drop the isolated state afterwards.

I am saying somethig like because you wouldn't really want a generic
has_unmovable_pages but rather
                if (!page_ref_count(page)) {
                        if (PageBuddy(page))
                                iter += (1 << page_order(page)) - 1;
                        continue;
                }
subset of it.

Nitesh Narayan Lal Sept. 11, 2019, 12:55 p.m. UTC | #21

On 9/11/19 8:42 AM, David Hildenbrand wrote:
> On 11.09.19 14:25, Michal Hocko wrote:
>> On Wed 11-09-19 14:19:41, Michal Hocko wrote:
>>> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
>>>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
>>>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
>>>>> [...]
>>>>>> We don't put any limitations on the allocator other then that it needs to
>>>>>> clean up the metadata on allocation, and that it cannot allocate a page
>>>>>> that is in the process of being reported since we pulled it from the
>>>>>> free_list. If the page is a "Reported" page then it decrements the
>>>>>> reported_pages count for the free_area and makes sure the page doesn't
>>>>>> exist in the "Boundary" array pointer value, if it does it moves the
>>>>>> "Boundary" since it is pulling the page.
>>>>> This is still a non-trivial limitation on the page allocation from an
>>>>> external code IMHO. I cannot give any explicit reason why an ordering on
>>>>> the free list might matter (well except for page shuffling which uses it
>>>>> to make physical memory pattern allocation more random) but the
>>>>> architecture seems hacky and dubious to be honest. It shoulds like the
>>>>> whole interface has been developed around a very particular and single
>>>>> purpose optimization.
>>>>>
>>>>> I remember that there was an attempt to report free memory that provided
>>>>> a callback mechanism [1], which was much less intrusive to the internals
>>>>> of the allocator yet it should provide a similar functionality. Did you
>>>>> see that approach? How does this compares to it? Or am I completely off
>>>>> when comparing them?
>>>>>
>>>>> [1] mostly likely not the latest version of the patchset
>>>>> http://lkml.kernel.org/r/[e-mail]
>>>> Linus nacked that one. He thinks invoking callbacks with lots of
>>>> internal mm locks is too fragile.
>>> I would be really curious how much he would be happy about injecting
>>> other restrictions on the allocator like this patch proposes. This is
>>> more intrusive as it has a higher maintenance cost longterm IMHO.
>> Btw. I do agree that callbacks with internal mm locks are not great
>> either. We do have a model for that in mmu_notifiers and it is something
>> I do consider PITA, on the other hand it is mostly sleepable part of the
>> interface which makes it the real pain. The above callback mechanism was
>> explicitly documented with restrictions and that the context is
>> essentially atomic with no access to particular struct pages and no
>> expensive operations possible. So in the end I've considered it
>> acceptably painful. Not that I want to override Linus' nack but if
>> virtualization usecases really require some form of reporting and no
>> other way to do that push people to invent even more interesting
>> approaches then we should simply give them/you something reasonable
>> and least intrusive to our internals.
>>
> The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
>  is that it cannot really handle the use case we have here if I am not
> wrong. While a page is getting processed by the hypervisor (e.g.
> MADV_DONTNEED), it must not get reused.
>
> "Some page blocks may
> leave the free list after zone->lock is released, so it is the caller's
> responsibility to either detect or prevent the use of such pages."
>
> If I'm not wrong, this only made sense to speed up migration in the
> hypervisor, where you can deal with false positives differently.

Another difference between the two approaches is the origin from where
the reporting request is getting generated. (If I remember correctly)
In Alexander's series or in my series [1], VM is able to report pages
dynamically without any requirement of host intervention.

[1] https://lkml.org/lkml/2019/8/12/593

David Hildenbrand Sept. 11, 2019, 1:03 p.m. UTC | #22

On 11.09.19 14:54, Michal Hocko wrote:
> On Wed 11-09-19 14:42:41, David Hildenbrand wrote:
>> On 11.09.19 14:25, Michal Hocko wrote:
>>> On Wed 11-09-19 14:19:41, Michal Hocko wrote:
>>>> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
>>>>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
>>>>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
>>>>>> [...]
>>>>>>> We don't put any limitations on the allocator other then that it needs to
>>>>>>> clean up the metadata on allocation, and that it cannot allocate a page
>>>>>>> that is in the process of being reported since we pulled it from the
>>>>>>> free_list. If the page is a "Reported" page then it decrements the
>>>>>>> reported_pages count for the free_area and makes sure the page doesn't
>>>>>>> exist in the "Boundary" array pointer value, if it does it moves the
>>>>>>> "Boundary" since it is pulling the page.
>>>>>>
>>>>>> This is still a non-trivial limitation on the page allocation from an
>>>>>> external code IMHO. I cannot give any explicit reason why an ordering on
>>>>>> the free list might matter (well except for page shuffling which uses it
>>>>>> to make physical memory pattern allocation more random) but the
>>>>>> architecture seems hacky and dubious to be honest. It shoulds like the
>>>>>> whole interface has been developed around a very particular and single
>>>>>> purpose optimization.
>>>>>>
>>>>>> I remember that there was an attempt to report free memory that provided
>>>>>> a callback mechanism [1], which was much less intrusive to the internals
>>>>>> of the allocator yet it should provide a similar functionality. Did you
>>>>>> see that approach? How does this compares to it? Or am I completely off
>>>>>> when comparing them?
>>>>>>
>>>>>> [1] mostly likely not the latest version of the patchset
>>>>>> http://lkml.kernel.org/r/[e-mail]
>>>>>
>>>>> Linus nacked that one. He thinks invoking callbacks with lots of
>>>>> internal mm locks is too fragile.
>>>>
>>>> I would be really curious how much he would be happy about injecting
>>>> other restrictions on the allocator like this patch proposes. This is
>>>> more intrusive as it has a higher maintenance cost longterm IMHO.
>>>
>>> Btw. I do agree that callbacks with internal mm locks are not great
>>> either. We do have a model for that in mmu_notifiers and it is something
>>> I do consider PITA, on the other hand it is mostly sleepable part of the
>>> interface which makes it the real pain. The above callback mechanism was
>>> explicitly documented with restrictions and that the context is
>>> essentially atomic with no access to particular struct pages and no
>>> expensive operations possible. So in the end I've considered it
>>> acceptably painful. Not that I want to override Linus' nack but if
>>> virtualization usecases really require some form of reporting and no
>>> other way to do that push people to invent even more interesting
>>> approaches then we should simply give them/you something reasonable
>>> and least intrusive to our internals.
>>>
>>
>> The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
>>  is that it cannot really handle the use case we have here if I am not
>> wrong. While a page is getting processed by the hypervisor (e.g.
>> MADV_DONTNEED), it must not get reused.
> 
> What prevents to use the callback to get a list of pfn ranges to work on
> and then use something like start_isolate_page_range on the collected
> pfn ranges to make sure nobody steals pages from under your feet, do
> your thing and drop the isolated state afterwards.
> 
> I am saying somethig like because you wouldn't really want a generic
> has_unmovable_pages but rather
>                 if (!page_ref_count(page)) {
>                         if (PageBuddy(page))
>                                 iter += (1 << page_order(page)) - 1;
>                         continue;
>                 }
> subset of it.
> 

Something slightly similar is being performed by Nitesh's patch set. On
every free of a certain granularity, he records it in the bitmap. These
bits are "hints of free pages".

A thread then walks over the bitmap and tries to allocate the "hints".
If the pages were already reused, the bit is silently cleared.

Instead of allocating/freeing, we could only try to isolate the
pageblock, then test if free. (One of the usual issues to work around is
MAX_ORDER-1 crossing pageblocks, that might need special care)

I think you should have a look at the rough idea of Nitesh's patch set
to see if something like that is going into a better direction. The
bitmap part is in place to do bulk reporting and avoid duplicate reports.

I think main points we want (and what I am missing from callback idea
being discussed) are
1. Do bulk reporting only when a certain threshold is reached
2. Report only bigger granularities (especially, avoid THP splits in the
hypervisor - >= 2MB proofed to be effective)
3. Avoid reporting what has just been reported.
4. Continuously report, not the "one time report everything" approach.

Nitesh Narayan Lal Sept. 11, 2019, 1:19 p.m. UTC | #23

On 9/11/19 8:54 AM, Michal Hocko wrote:
> On Wed 11-09-19 14:42:41, David Hildenbrand wrote:
>> On 11.09.19 14:25, Michal Hocko wrote:
>>> On Wed 11-09-19 14:19:41, Michal Hocko wrote:
>>>> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
>>>>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
>>>>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
>>>>>> [...]
>>>>>>> We don't put any limitations on the allocator other then that it needs to
>>>>>>> clean up the metadata on allocation, and that it cannot allocate a page
>>>>>>> that is in the process of being reported since we pulled it from the
>>>>>>> free_list. If the page is a "Reported" page then it decrements the
>>>>>>> reported_pages count for the free_area and makes sure the page doesn't
>>>>>>> exist in the "Boundary" array pointer value, if it does it moves the
>>>>>>> "Boundary" since it is pulling the page.
>>>>>> This is still a non-trivial limitation on the page allocation from an
>>>>>> external code IMHO. I cannot give any explicit reason why an ordering on
>>>>>> the free list might matter (well except for page shuffling which uses it
>>>>>> to make physical memory pattern allocation more random) but the
>>>>>> architecture seems hacky and dubious to be honest. It shoulds like the
>>>>>> whole interface has been developed around a very particular and single
>>>>>> purpose optimization.
>>>>>>
>>>>>> I remember that there was an attempt to report free memory that provided
>>>>>> a callback mechanism [1], which was much less intrusive to the internals
>>>>>> of the allocator yet it should provide a similar functionality. Did you
>>>>>> see that approach? How does this compares to it? Or am I completely off
>>>>>> when comparing them?
>>>>>>
>>>>>> [1] mostly likely not the latest version of the patchset
>>>>>> http://lkml.kernel.org/r/[e-mail]
>>>>> Linus nacked that one. He thinks invoking callbacks with lots of
>>>>> internal mm locks is too fragile.
>>>> I would be really curious how much he would be happy about injecting
>>>> other restrictions on the allocator like this patch proposes. This is
>>>> more intrusive as it has a higher maintenance cost longterm IMHO.
>>> Btw. I do agree that callbacks with internal mm locks are not great
>>> either. We do have a model for that in mmu_notifiers and it is something
>>> I do consider PITA, on the other hand it is mostly sleepable part of the
>>> interface which makes it the real pain. The above callback mechanism was
>>> explicitly documented with restrictions and that the context is
>>> essentially atomic with no access to particular struct pages and no
>>> expensive operations possible. So in the end I've considered it
>>> acceptably painful. Not that I want to override Linus' nack but if
>>> virtualization usecases really require some form of reporting and no
>>> other way to do that push people to invent even more interesting
>>> approaches then we should simply give them/you something reasonable
>>> and least intrusive to our internals.
>>>
>> The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
>>  is that it cannot really handle the use case we have here if I am not
>> wrong. While a page is getting processed by the hypervisor (e.g.
>> MADV_DONTNEED), it must not get reused.
> What prevents to use the callback to get a list of pfn ranges to work on
> and then use something like start_isolate_page_range on the collected
> pfn ranges to make sure nobody steals pages from under your feet, do
> your thing and drop the isolated state afterwards.
>

In my series, I am doing something similar.
- Track (MAX_ORDER - 2) free pages in bitmap maintained on a per-zone
  basis.
- Use __isolate_free_page on the pages marked in the bitmap and are
  still free.
- Report chunks of 16 isolated pages to the hypervisor.
- Return them back to the buddy once the request is processed.

> I am saying somethig like because you wouldn't really want a generic
> has_unmovable_pages but rather
>                 if (!page_ref_count(page)) {
>                         if (PageBuddy(page))
>                                 iter += (1 << page_order(page)) - 1;
>                         continue;
>                 }
> subset of it.

Michal Hocko Sept. 11, 2019, 1:20 p.m. UTC | #24

On Wed 11-09-19 15:03:39, David Hildenbrand wrote:
> On 11.09.19 14:54, Michal Hocko wrote:
> > On Wed 11-09-19 14:42:41, David Hildenbrand wrote:
> >> On 11.09.19 14:25, Michal Hocko wrote:
> >>> On Wed 11-09-19 14:19:41, Michal Hocko wrote:
> >>>> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
> >>>>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
> >>>>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> >>>>>> [...]
> >>>>>>> We don't put any limitations on the allocator other then that it needs to
> >>>>>>> clean up the metadata on allocation, and that it cannot allocate a page
> >>>>>>> that is in the process of being reported since we pulled it from the
> >>>>>>> free_list. If the page is a "Reported" page then it decrements the
> >>>>>>> reported_pages count for the free_area and makes sure the page doesn't
> >>>>>>> exist in the "Boundary" array pointer value, if it does it moves the
> >>>>>>> "Boundary" since it is pulling the page.
> >>>>>>
> >>>>>> This is still a non-trivial limitation on the page allocation from an
> >>>>>> external code IMHO. I cannot give any explicit reason why an ordering on
> >>>>>> the free list might matter (well except for page shuffling which uses it
> >>>>>> to make physical memory pattern allocation more random) but the
> >>>>>> architecture seems hacky and dubious to be honest. It shoulds like the
> >>>>>> whole interface has been developed around a very particular and single
> >>>>>> purpose optimization.
> >>>>>>
> >>>>>> I remember that there was an attempt to report free memory that provided
> >>>>>> a callback mechanism [1], which was much less intrusive to the internals
> >>>>>> of the allocator yet it should provide a similar functionality. Did you
> >>>>>> see that approach? How does this compares to it? Or am I completely off
> >>>>>> when comparing them?
> >>>>>>
> >>>>>> [1] mostly likely not the latest version of the patchset
> >>>>>> http://lkml.kernel.org/r/[e-mail]
> >>>>>
> >>>>> Linus nacked that one. He thinks invoking callbacks with lots of
> >>>>> internal mm locks is too fragile.
> >>>>
> >>>> I would be really curious how much he would be happy about injecting
> >>>> other restrictions on the allocator like this patch proposes. This is
> >>>> more intrusive as it has a higher maintenance cost longterm IMHO.
> >>>
> >>> Btw. I do agree that callbacks with internal mm locks are not great
> >>> either. We do have a model for that in mmu_notifiers and it is something
> >>> I do consider PITA, on the other hand it is mostly sleepable part of the
> >>> interface which makes it the real pain. The above callback mechanism was
> >>> explicitly documented with restrictions and that the context is
> >>> essentially atomic with no access to particular struct pages and no
> >>> expensive operations possible. So in the end I've considered it
> >>> acceptably painful. Not that I want to override Linus' nack but if
> >>> virtualization usecases really require some form of reporting and no
> >>> other way to do that push people to invent even more interesting
> >>> approaches then we should simply give them/you something reasonable
> >>> and least intrusive to our internals.
> >>>
> >>
> >> The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
> >>  is that it cannot really handle the use case we have here if I am not
> >> wrong. While a page is getting processed by the hypervisor (e.g.
> >> MADV_DONTNEED), it must not get reused.
> > 
> > What prevents to use the callback to get a list of pfn ranges to work on
> > and then use something like start_isolate_page_range on the collected
> > pfn ranges to make sure nobody steals pages from under your feet, do
> > your thing and drop the isolated state afterwards.
> > 
> > I am saying somethig like because you wouldn't really want a generic
> > has_unmovable_pages but rather
> >                 if (!page_ref_count(page)) {
> >                         if (PageBuddy(page))
> >                                 iter += (1 << page_order(page)) - 1;
> >                         continue;
> >                 }
> > subset of it.
> > 
> 
> Something slightly similar is being performed by Nitesh's patch set. On
> every free of a certain granularity, he records it in the bitmap. These
> bits are "hints of free pages".
> 
> A thread then walks over the bitmap and tries to allocate the "hints".
> If the pages were already reused, the bit is silently cleared.
> 
> Instead of allocating/freeing, we could only try to isolate the
> pageblock, then test if free. (One of the usual issues to work around is
> MAX_ORDER-1 crossing pageblocks, that might need special care)

OK, cool that I have reinvented the wheel ;). Allocation is indeed not
necessary as long as pages are isolated because nobody will allocate
them.
 
> I think you should have a look at the rough idea of Nitesh's patch set
> to see if something like that is going into a better direction. The
> bitmap part is in place to do bulk reporting and avoid duplicate reports.

Let's see how much time I can find for that in my endless inbox whack a mole.
 
> I think main points we want (and what I am missing from callback idea
> being discussed) are
> 1. Do bulk reporting only when a certain threshold is reached

Is a time based approach too coarse?

> 2. Report only bigger granularities (especially, avoid THP splits in the
> hypervisor - >= 2MB proofed to be effective)

the callback has supported order based scan in some of its iteration.

> 3. Avoid reporting what has just been reported.

Is the overhead of checking a pfn range in a bitmask that much of an
overhead to really care?

> 4. Continuously report, not the "one time report everything" approach.

So you mean the allocator reporting this rather than an external code to
poll right? I do not know, how much this is nice to have than must have?

Michal Hocko Sept. 11, 2019, 1:51 p.m. UTC | #25

On Wed 11-09-19 15:20:02, Michal Hocko wrote:
[...]
> > 4. Continuously report, not the "one time report everything" approach.
> 
> So you mean the allocator reporting this rather than an external code to
> poll right? I do not know, how much this is nice to have than must have?

Another idea that I haven't really thought through so it might turned
out to be completely bogus but let's try anyway. Your "report everything"
just made me look and realize that free_pages_prepare already performs
stuff that actually does something similar yet unrelated.

We do report to special page poisoning, zeroying or
CONFIG_DEBUG_PAGEALLOC to unmap the address from the kernel address
space. This sounds like something fitting your model no?

Nitesh Narayan Lal Sept. 11, 2019, 2:03 p.m. UTC | #26

On 9/11/19 9:20 AM, Michal Hocko wrote:
> On Wed 11-09-19 15:03:39, David Hildenbrand wrote:
>> On 11.09.19 14:54, Michal Hocko wrote:
>>> On Wed 11-09-19 14:42:41, David Hildenbrand wrote:
>>>> On 11.09.19 14:25, Michal Hocko wrote:
>>>>> On Wed 11-09-19 14:19:41, Michal Hocko wrote:
>>>>>> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
>>>>>>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
>>>>>>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
>>>>>>>> [...]
>>>>>>>>> We don't put any limitations on the allocator other then that it needs to
>>>>>>>>> clean up the metadata on allocation, and that it cannot allocate a page
>>>>>>>>> that is in the process of being reported since we pulled it from the
>>>>>>>>> free_list. If the page is a "Reported" page then it decrements the
>>>>>>>>> reported_pages count for the free_area and makes sure the page doesn't
>>>>>>>>> exist in the "Boundary" array pointer value, if it does it moves the
>>>>>>>>> "Boundary" since it is pulling the page.
>>>>>>>> This is still a non-trivial limitation on the page allocation from an
>>>>>>>> external code IMHO. I cannot give any explicit reason why an ordering on
>>>>>>>> the free list might matter (well except for page shuffling which uses it
>>>>>>>> to make physical memory pattern allocation more random) but the
>>>>>>>> architecture seems hacky and dubious to be honest. It shoulds like the
>>>>>>>> whole interface has been developed around a very particular and single
>>>>>>>> purpose optimization.
>>>>>>>>
>>>>>>>> I remember that there was an attempt to report free memory that provided
>>>>>>>> a callback mechanism [1], which was much less intrusive to the internals
>>>>>>>> of the allocator yet it should provide a similar functionality. Did you
>>>>>>>> see that approach? How does this compares to it? Or am I completely off
>>>>>>>> when comparing them?
>>>>>>>>
>>>>>>>> [1] mostly likely not the latest version of the patchset
>>>>>>>> http://lkml.kernel.org/r/[e-mail]
>>>>>>> Linus nacked that one. He thinks invoking callbacks with lots of
>>>>>>> internal mm locks is too fragile.
>>>>>> I would be really curious how much he would be happy about injecting
>>>>>> other restrictions on the allocator like this patch proposes. This is
>>>>>> more intrusive as it has a higher maintenance cost longterm IMHO.
>>>>> Btw. I do agree that callbacks with internal mm locks are not great
>>>>> either. We do have a model for that in mmu_notifiers and it is something
>>>>> I do consider PITA, on the other hand it is mostly sleepable part of the
>>>>> interface which makes it the real pain. The above callback mechanism was
>>>>> explicitly documented with restrictions and that the context is
>>>>> essentially atomic with no access to particular struct pages and no
>>>>> expensive operations possible. So in the end I've considered it
>>>>> acceptably painful. Not that I want to override Linus' nack but if
>>>>> virtualization usecases really require some form of reporting and no
>>>>> other way to do that push people to invent even more interesting
>>>>> approaches then we should simply give them/you something reasonable
>>>>> and least intrusive to our internals.
>>>>>
>>>> The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
>>>>  is that it cannot really handle the use case we have here if I am not
>>>> wrong. While a page is getting processed by the hypervisor (e.g.
>>>> MADV_DONTNEED), it must not get reused.
>>> What prevents to use the callback to get a list of pfn ranges to work on
>>> and then use something like start_isolate_page_range on the collected
>>> pfn ranges to make sure nobody steals pages from under your feet, do
>>> your thing and drop the isolated state afterwards.
>>>
>>> I am saying somethig like because you wouldn't really want a generic
>>> has_unmovable_pages but rather
>>>                 if (!page_ref_count(page)) {
>>>                         if (PageBuddy(page))
>>>                                 iter += (1 << page_order(page)) - 1;
>>>                         continue;
>>>                 }
>>> subset of it.
>>>
>> Something slightly similar is being performed by Nitesh's patch set. On
>> every free of a certain granularity, he records it in the bitmap. These
>> bits are "hints of free pages".
>>
>> A thread then walks over the bitmap and tries to allocate the "hints".
>> If the pages were already reused, the bit is silently cleared.
>>
>> Instead of allocating/freeing, we could only try to isolate the
>> pageblock, then test if free. (One of the usual issues to work around is
>> MAX_ORDER-1 crossing pageblocks, that might need special care)
> OK, cool that I have reinvented the wheel ;). Allocation is indeed not
> necessary as long as pages are isolated because nobody will allocate
> them.
>  
>> I think you should have a look at the rough idea of Nitesh's patch set
>> to see if something like that is going into a better direction. The
>> bitmap part is in place to do bulk reporting and avoid duplicate reports.
> Let's see how much time I can find for that in my endless inbox whack a mole.
>  
>> I think main points we want (and what I am missing from callback idea
>> being discussed) are
>> 1. Do bulk reporting only when a certain threshold is reached
> Is a time based approach too coarse?

I haven't looked into it yet. One situation which I would definitely
want to avoid is to unnecessary invoke bitmap scans when there are not
sufficient free pages available in the zone.
I can take a look at it if required.


>
>> 2. Report only bigger granularities (especially, avoid THP splits in the
>> hypervisor - >= 2MB proofed to be effective)
> the callback has supported order based scan in some of its iteration.
>
>> 3. Avoid reporting what has just been reported.
> Is the overhead of checking a pfn range in a bitmask that much of an
> overhead to really care?

In most of the cases No. Similar to Alexander I was also running will-it-scale/
page_fault1 to analyze the performance impact of the patch series and haven't
noticed any significant degradation.
In some specific cases, we may see noticeable degradation due to the scanning
overhead.

>
>> 4. Continuously report, not the "one time report everything" approach.
> So you mean the allocator reporting this rather than an external code to
> poll right? I do not know, how much this is nice to have than must have?

Not sure if I understood the question completely.
But yes in my case any workload which is allocating and freeing pages will end
up initiating reporting requests based on the number of free pages in the zone.

Alexander Duyck Sept. 11, 2019, 3:12 p.m. UTC | #27

On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <[e-mail]> wrote:
>
> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> [...]
> > We don't put any limitations on the allocator other then that it needs to
> > clean up the metadata on allocation, and that it cannot allocate a page
> > that is in the process of being reported since we pulled it from the
> > free_list. If the page is a "Reported" page then it decrements the
> > reported_pages count for the free_area and makes sure the page doesn't
> > exist in the "Boundary" array pointer value, if it does it moves the
> > "Boundary" since it is pulling the page.
>
> This is still a non-trivial limitation on the page allocation from an
> external code IMHO. I cannot give any explicit reason why an ordering on
> the free list might matter (well except for page shuffling which uses it
> to make physical memory pattern allocation more random) but the
> architecture seems hacky and dubious to be honest. It shoulds like the
> whole interface has been developed around a very particular and single
> purpose optimization.

How is this any different then the code that moves a page that will
likely be merged to the tail though?

In our case the "Reported" page is likely going to be much more
expensive to allocate and use then a standard page because it will be
faulted back in. In such a case wouldn't it make sense for us to want
to keep the pages that don't require faults ahead of those pages in
the free_list so that they are more likely to be allocated? All we are
doing with the boundary list is preventing still resident pages from
being deferred behind pages that would require a page fault to get
access to.

> I remember that there was an attempt to report free memory that provided
> a callback mechanism [1], which was much less intrusive to the internals
> of the allocator yet it should provide a similar functionality. Did you
> see that approach? How does this compares to it? Or am I completely off
> when comparing them?
>
> [1] mostly likely not the latest version of the patchset
> http://lkml.kernel.org/r/[e-mail]

There have been a few comparisons between this patch set and the ones
from Wei Wang. In regards to the one you are pointing to the main
difference is that I am not permanently locking memory. Basically what
happens is that the iterator will take the lock, pull a few pages,
release the lock while reporting them, and then take the lock to
return those pages, grab some more, and repeat.

I was actually influenced somewhat by the suggestions that patchset
received, specifically I believe it resembles something like what was
suggested by Linus in response to v35 of that patch set:
https://lore.kernel.org/linux-mm/[e-mail]/

Basically where the feature Wei Wang was working on differs from this
patch set is that I need this to run continually, his only needed to
run periodically as he was just trying to identify free pages at a
fixed point in time. My goal is to identify pages that have been freed
since the last time I reported them. To do that I need a flag in the
page to identify those pages, and an iterator in the form of a
boundary pointer so that I can incrementally walk through the list
without losing track of freed pages.

David Hildenbrand Sept. 11, 2019, 4:02 p.m. UTC | #28

>> Something slightly similar is being performed by Nitesh's patch set. On
>> every free of a certain granularity, he records it in the bitmap. These
>> bits are "hints of free pages".
>>
>> A thread then walks over the bitmap and tries to allocate the "hints".
>> If the pages were already reused, the bit is silently cleared.
>>
>> Instead of allocating/freeing, we could only try to isolate the
>> pageblock, then test if free. (One of the usual issues to work around is
>> MAX_ORDER-1 crossing pageblocks, that might need special care)
> 
> OK, cool that I have reinvented the wheel ;). Allocation is indeed not
> necessary as long as pages are isolated because nobody will allocate
> them.

It's always good if you come to the same conclusion ;)

>  
>> I think you should have a look at the rough idea of Nitesh's patch set
>> to see if something like that is going into a better direction. The
>> bitmap part is in place to do bulk reporting and avoid duplicate reports.
> 
> Let's see how much time I can find for that in my endless inbox whack a mole.

Can totally understand - it's only a single patch.

>  
>> I think main points we want (and what I am missing from callback idea
>> being discussed) are
>> 1. Do bulk reporting only when a certain threshold is reached
> 
> Is a time based approach too coarse?

Usually that's then another parameter to fine tune, something to avoid
when just reporting continuously. I wouldn't say it's a no go, but at
least I would prefer right now to do it continuously.

> 
>> 2. Report only bigger granularities (especially, avoid THP splits in the
>> hypervisor - >= 2MB proofed to be effective)
> 
> the callback has supported order based scan in some of its iteration.

Missed that. But yeah, the other points are more important :)

> 
>> 3. Avoid reporting what has just been reported.
> 
> Is the overhead of checking a pfn range in a bitmask that much of an
> overhead to really care?

It's all about remembering what has already been reported. Nitesh solved
that via the bitmap. So he does exactly that. If we can optimize the
bitmap out - perfect - but I don't see an easy way to do that :)

> 
>> 4. Continuously report, not the "one time report everything" approach.
> 
> So you mean the allocator reporting this rather than an external code to
> poll right? I do not know, how much this is nice to have than must have?

I guess it is debatable - but I don't consider this one of the
fundamental issues. How to identify what to report and remember what has
already been reported is the main issue. Polling vs. notification is
just the cherry on top - IMHO.

David Hildenbrand Sept. 11, 2019, 4:09 p.m. UTC | #29

On 11.09.19 15:51, Michal Hocko wrote:
> On Wed 11-09-19 15:20:02, Michal Hocko wrote:
> [...]
>>> 4. Continuously report, not the "one time report everything" approach.
>>
>> So you mean the allocator reporting this rather than an external code to
>> poll right? I do not know, how much this is nice to have than must have?
> 
> Another idea that I haven't really thought through so it might turned
> out to be completely bogus but let's try anyway. Your "report everything"
> just made me look and realize that free_pages_prepare already performs
> stuff that actually does something similar yet unrelated.
> 
> We do report to special page poisoning, zeroying or
> CONFIG_DEBUG_PAGEALLOC to unmap the address from the kernel address
> space. This sounds like something fitting your model no?
> 

AFAIKS, the poisoning/unmapping is done whenever a page is freed. I
don't quite see yet how that would help to remember if a page was
already reported. After reporting the page we would have to switch some
state (Nitesh: bitmap bit, Alexander: page flag) to identify that.

Of course, we could map the page and treat that as "the state" when we
reported it, but I am not sure that's such a good idea :)

As always, I might be very wrong ...

Michal Hocko Sept. 12, 2019, 7:16 a.m. UTC | #30

On Wed 11-09-19 18:09:18, David Hildenbrand wrote:
> On 11.09.19 15:51, Michal Hocko wrote:
> > On Wed 11-09-19 15:20:02, Michal Hocko wrote:
> > [...]
> >>> 4. Continuously report, not the "one time report everything" approach.
> >>
> >> So you mean the allocator reporting this rather than an external code to
> >> poll right? I do not know, how much this is nice to have than must have?
> > 
> > Another idea that I haven't really thought through so it might turned
> > out to be completely bogus but let's try anyway. Your "report everything"
> > just made me look and realize that free_pages_prepare already performs
> > stuff that actually does something similar yet unrelated.
> > 
> > We do report to special page poisoning, zeroying or
> > CONFIG_DEBUG_PAGEALLOC to unmap the address from the kernel address
> > space. This sounds like something fitting your model no?
> > 
> 
> AFAIKS, the poisoning/unmapping is done whenever a page is freed. I
> don't quite see yet how that would help to remember if a page was
> already reported.

Do you still have to differ that state when each page is reported?

> After reporting the page we would have to switch some
> state (Nitesh: bitmap bit, Alexander: page flag) to identify that.

Yes, you can either store the state somewhere.

> Of course, we could map the page and treat that as "the state" when we
> reported it, but I am not sure that's such a good idea :)
> 
> As always, I might be very wrong ...

I still do not fully understand the usecase so I might be equally wrong.
My thinking is along these lines. Why should you scan free pages when
you can effectively capture each freed page? If you go one step further
then post_alloc_hook would be the counterpart to know that your page has
been allocated.

David Hildenbrand Sept. 12, 2019, 7:47 a.m. UTC | #31

On 12.09.19 09:16, Michal Hocko wrote:
> On Wed 11-09-19 18:09:18, David Hildenbrand wrote:
>> On 11.09.19 15:51, Michal Hocko wrote:
>>> On Wed 11-09-19 15:20:02, Michal Hocko wrote:
>>> [...]
>>>>> 4. Continuously report, not the "one time report everything" approach.
>>>>
>>>> So you mean the allocator reporting this rather than an external code to
>>>> poll right? I do not know, how much this is nice to have than must have?
>>>
>>> Another idea that I haven't really thought through so it might turned
>>> out to be completely bogus but let's try anyway. Your "report everything"
>>> just made me look and realize that free_pages_prepare already performs
>>> stuff that actually does something similar yet unrelated.
>>>
>>> We do report to special page poisoning, zeroying or
>>> CONFIG_DEBUG_PAGEALLOC to unmap the address from the kernel address
>>> space. This sounds like something fitting your model no?
>>>
>>
>> AFAIKS, the poisoning/unmapping is done whenever a page is freed. I
>> don't quite see yet how that would help to remember if a page was
>> already reported.
> 
> Do you still have to differ that state when each page is reported?

Ah, very good point. I can see that the reason for this was not
discussed in this thread so far. (Alexander, Nitesh, please correct me
if I am wrong). It's buried in the long history of free page
hinting/reporting.

Some early patch sets tried to report during every free synchronously.
Free a page, report them to the hypervisor. This resulted in some issues
(especially, locking-related and the virtio + the hypervisor being
involved, resulting in unpredictable delays, quite some overhead ...).
It was no good.

One design decision then was to not report single pages, but a bunch of
pages at once. This made it necessary to "remember" the pages to be
reported and to temporarily block them from getting allocated while
reporting.

Nitesh implemented (at least) two "capture PFNs of free pages in an
array when freeing" approaches. One being synchronous from the freeing
CPU once the list was full (having similar issues as plain synchronous
reporting) and one being asynchronous by a separate thread (which solved
many locking issues).

Turned out the a simple array can quickly lead to us having to drop
"reports" to the hypervisor because the array is full and the reporting
thread was not able to keep up. Not good as well. Especially, if some
process frees a lot of memory this can happen quickly and Nitesh wa
sable to trigger this scenario frequently.

Finally, Nitesh decided to use the bitmap instead to keep track of pages
to report. I'd like to note that this approach could still be combined
with an "array of potentially free PFNs". Only when the array/circular
buffer runs out of entries ("reporting thread cannot keep up"), we would
have to go back to scanning the bitmap.

That was also the point where Alexander decided to look into integrating
tracking/handling reported/unreported pages directly in the buddy.

> 
>> After reporting the page we would have to switch some
>> state (Nitesh: bitmap bit, Alexander: page flag) to identify that.
> 
> Yes, you can either store the state somewhere.
> 
>> Of course, we could map the page and treat that as "the state" when we
>> reported it, but I am not sure that's such a good idea :)
>>
>> As always, I might be very wrong ...
> 
> I still do not fully understand the usecase so I might be equally wrong.
> My thinking is along these lines. Why should you scan free pages when
> you can effectively capture each freed page? If you go one step further
> then post_alloc_hook would be the counterpart to know that your page has
> been allocated.

I'd like to note that Nitesh's patch set contains the following hunk,
which is roughly what you were thinking :)


-static inline void __free_one_page(struct page *page,
+inline void __free_one_page(struct page *page,
 		unsigned long pfn,
 		struct zone *zone, unsigned int order,
-		int migratetype)
+		int migratetype, bool hint)
 {
 	unsigned long combined_pfn;
 	unsigned long uninitialized_var(buddy_pfn);
@@ -980,7 +981,8 @@ static inline void __free_one_page(struct page *page,
 				migratetype);
 	else
 		add_to_free_area(page, &zone->free_area[order], migratetype);
-
+	if (hint)
+		page_hinting_enqueue(page, order);
 }


(ignore the hint parameter, when he would switch to a isolate vs.
alloc/free, that can go away and all we left is the enqueue part)


Inside that callback we can remember the pages any way we want. Right
now in a bitmap. Maybe later in a array + bitmap (as discussed above).
Another idea I had was to simply go over all pages and report them when
running into this "array full" condition. But I am not yet sure about
the performance implications on rather large machines. So the bitmap
idea might have some other limitations but seems to do its job.

Hoe that makes things clearer and am not missing something.

Michal Hocko Sept. 12, 2019, 9:19 a.m. UTC | #32

On Wed 11-09-19 08:12:03, Alexander Duyck wrote:
> On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <[e-mail]> wrote:
> >
> > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > [...]
> > > We don't put any limitations on the allocator other then that it needs to
> > > clean up the metadata on allocation, and that it cannot allocate a page
> > > that is in the process of being reported since we pulled it from the
> > > free_list. If the page is a "Reported" page then it decrements the
> > > reported_pages count for the free_area and makes sure the page doesn't
> > > exist in the "Boundary" array pointer value, if it does it moves the
> > > "Boundary" since it is pulling the page.
> >
> > This is still a non-trivial limitation on the page allocation from an
> > external code IMHO. I cannot give any explicit reason why an ordering on
> > the free list might matter (well except for page shuffling which uses it
> > to make physical memory pattern allocation more random) but the
> > architecture seems hacky and dubious to be honest. It shoulds like the
> > whole interface has been developed around a very particular and single
> > purpose optimization.
> 
> How is this any different then the code that moves a page that will
> likely be merged to the tail though?

I guess you are referring to the page shuffling. If that is the case
then this is an integral part of the allocator for a reason and it is
very well obvious in the code including the consequences. I do not
really like an idea of hiding similar constrains behind a generic
looking feature which is completely detached from the allocator and so
any future change of the allocator might subtly break it.

> In our case the "Reported" page is likely going to be much more
> expensive to allocate and use then a standard page because it will be
> faulted back in. In such a case wouldn't it make sense for us to want
> to keep the pages that don't require faults ahead of those pages in
> the free_list so that they are more likely to be allocated?

OK, I was suspecting this would pop out. And this is exactly why I
didn't like an idea of an external code imposing a non obvious constrains
to the allocator. You simply cannot count with any ordering with the
page allocator. We used to distinguish cache hot/cold pages in the past
and pushed pages to the specific end of the free list but that has been
removed. There are other potential changes like that possible. Shuffling
is a good recent example.

Anyway I am not a maintainer of this code. I would really like to hear
opinions from Mel and Vlastimil here (now CCed - the thread starts
http://lkml.kernel.org/r/[e-mail].

Michal Hocko Sept. 12, 2019, 9:26 a.m. UTC | #33

On Thu 12-09-19 09:47:30, David Hildenbrand wrote:
> On 12.09.19 09:16, Michal Hocko wrote:
> > On Wed 11-09-19 18:09:18, David Hildenbrand wrote:
> >> On 11.09.19 15:51, Michal Hocko wrote:
> >>> On Wed 11-09-19 15:20:02, Michal Hocko wrote:
> >>> [...]
> >>>>> 4. Continuously report, not the "one time report everything" approach.
> >>>>
> >>>> So you mean the allocator reporting this rather than an external code to
> >>>> poll right? I do not know, how much this is nice to have than must have?
> >>>
> >>> Another idea that I haven't really thought through so it might turned
> >>> out to be completely bogus but let's try anyway. Your "report everything"
> >>> just made me look and realize that free_pages_prepare already performs
> >>> stuff that actually does something similar yet unrelated.
> >>>
> >>> We do report to special page poisoning, zeroying or
> >>> CONFIG_DEBUG_PAGEALLOC to unmap the address from the kernel address
> >>> space. This sounds like something fitting your model no?
> >>>
> >>
> >> AFAIKS, the poisoning/unmapping is done whenever a page is freed. I
> >> don't quite see yet how that would help to remember if a page was
> >> already reported.
> > 
> > Do you still have to differ that state when each page is reported?
> 
> Ah, very good point. I can see that the reason for this was not
> discussed in this thread so far. (Alexander, Nitesh, please correct me
> if I am wrong). It's buried in the long history of free page
> hinting/reporting.

It would really be preferable to summarize such a previous discussion
ideally with some references.

> Some early patch sets tried to report during every free synchronously.
> Free a page, report them to the hypervisor. This resulted in some issues
> (especially, locking-related and the virtio + the hypervisor being
> involved, resulting in unpredictable delays, quite some overhead ...).
> It was no good.
> 
> One design decision then was to not report single pages, but a bunch of
> pages at once. This made it necessary to "remember" the pages to be
> reported and to temporarily block them from getting allocated while
> reporting.
> 
> Nitesh implemented (at least) two "capture PFNs of free pages in an
> array when freeing" approaches. One being synchronous from the freeing
> CPU once the list was full (having similar issues as plain synchronous
> reporting) and one being asynchronous by a separate thread (which solved
> many locking issues).
> 
> Turned out the a simple array can quickly lead to us having to drop
> "reports" to the hypervisor because the array is full and the reporting
> thread was not able to keep up. Not good as well. Especially, if some
> process frees a lot of memory this can happen quickly and Nitesh wa
> sable to trigger this scenario frequently.
> 
> Finally, Nitesh decided to use the bitmap instead to keep track of pages
> to report. I'd like to note that this approach could still be combined
> with an "array of potentially free PFNs". Only when the array/circular
> buffer runs out of entries ("reporting thread cannot keep up"), we would
> have to go back to scanning the bitmap.
> 
> That was also the point where Alexander decided to look into integrating
> tracking/handling reported/unreported pages directly in the buddy.

OK, this gives at least some background which is really appreciated.
Explaining _why_ you need something in the core MM is essential to move
forward.
 
> >> After reporting the page we would have to switch some
> >> state (Nitesh: bitmap bit, Alexander: page flag) to identify that.
> > 
> > Yes, you can either store the state somewhere.
> > 
> >> Of course, we could map the page and treat that as "the state" when we
> >> reported it, but I am not sure that's such a good idea :)
> >>
> >> As always, I might be very wrong ...
> > 
> > I still do not fully understand the usecase so I might be equally wrong.
> > My thinking is along these lines. Why should you scan free pages when
> > you can effectively capture each freed page? If you go one step further
> > then post_alloc_hook would be the counterpart to know that your page has
> > been allocated.
> 
> I'd like to note that Nitesh's patch set contains the following hunk,
> which is roughly what you were thinking :)
> 
> 
> -static inline void __free_one_page(struct page *page,
> +inline void __free_one_page(struct page *page,
>  		unsigned long pfn,
>  		struct zone *zone, unsigned int order,
> -		int migratetype)
> +		int migratetype, bool hint)
>  {
>  	unsigned long combined_pfn;
>  	unsigned long uninitialized_var(buddy_pfn);
> @@ -980,7 +981,8 @@ static inline void __free_one_page(struct page *page,
>  				migratetype);
>  	else
>  		add_to_free_area(page, &zone->free_area[order], migratetype);
> -
> +	if (hint)
> +		page_hinting_enqueue(page, order);
>  }
> 
> 
> (ignore the hint parameter, when he would switch to a isolate vs.
> alloc/free, that can go away and all we left is the enqueue part)
> 
> 
> Inside that callback we can remember the pages any way we want. Right
> now in a bitmap. Maybe later in a array + bitmap (as discussed above).
> Another idea I had was to simply go over all pages and report them when
> running into this "array full" condition. But I am not yet sure about
> the performance implications on rather large machines. So the bitmap
> idea might have some other limitations but seems to do its job.
> 
> Hoe that makes things clearer and am not missing something.

It certainly helped me to get a better idea. I have commented on my
reservations regarding the approach in this thread elsewhere but at
least I _think_ I am getting a point of what you guys try to achieve.

Thanks!

Kirill A. Shutemov Sept. 12, 2019, 10:24 a.m. UTC | #34

On Thu, Sep 12, 2019 at 11:19:25AM +0200, Michal Hocko wrote:
> On Wed 11-09-19 08:12:03, Alexander Duyck wrote:
> > On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <[e-mail]> wrote:
> > >
> > > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > > [...]
> > > > We don't put any limitations on the allocator other then that it needs to
> > > > clean up the metadata on allocation, and that it cannot allocate a page
> > > > that is in the process of being reported since we pulled it from the
> > > > free_list. If the page is a "Reported" page then it decrements the
> > > > reported_pages count for the free_area and makes sure the page doesn't
> > > > exist in the "Boundary" array pointer value, if it does it moves the
> > > > "Boundary" since it is pulling the page.
> > >
> > > This is still a non-trivial limitation on the page allocation from an
> > > external code IMHO. I cannot give any explicit reason why an ordering on
> > > the free list might matter (well except for page shuffling which uses it
> > > to make physical memory pattern allocation more random) but the
> > > architecture seems hacky and dubious to be honest. It shoulds like the
> > > whole interface has been developed around a very particular and single
> > > purpose optimization.
> > 
> > How is this any different then the code that moves a page that will
> > likely be merged to the tail though?
> 
> I guess you are referring to the page shuffling. If that is the case
> then this is an integral part of the allocator for a reason and it is
> very well obvious in the code including the consequences. I do not
> really like an idea of hiding similar constrains behind a generic
> looking feature which is completely detached from the allocator and so
> any future change of the allocator might subtly break it.

I don't necessary follow why shuffling is more integral to page allocator
than reporting would be. It's next to shutffle.c under mm/ and integrated
in a simillar way.

Michal Hocko Sept. 12, 2019, 11:11 a.m. UTC | #35

On Thu 12-09-19 13:24:25, Kirill A. Shutemov wrote:
> On Thu, Sep 12, 2019 at 11:19:25AM +0200, Michal Hocko wrote:
> > On Wed 11-09-19 08:12:03, Alexander Duyck wrote:
> > > On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <[e-mail]> wrote:
> > > >
> > > > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > > > [...]
> > > > > We don't put any limitations on the allocator other then that it needs to
> > > > > clean up the metadata on allocation, and that it cannot allocate a page
> > > > > that is in the process of being reported since we pulled it from the
> > > > > free_list. If the page is a "Reported" page then it decrements the
> > > > > reported_pages count for the free_area and makes sure the page doesn't
> > > > > exist in the "Boundary" array pointer value, if it does it moves the
> > > > > "Boundary" since it is pulling the page.
> > > >
> > > > This is still a non-trivial limitation on the page allocation from an
> > > > external code IMHO. I cannot give any explicit reason why an ordering on
> > > > the free list might matter (well except for page shuffling which uses it
> > > > to make physical memory pattern allocation more random) but the
> > > > architecture seems hacky and dubious to be honest. It shoulds like the
> > > > whole interface has been developed around a very particular and single
> > > > purpose optimization.
> > > 
> > > How is this any different then the code that moves a page that will
> > > likely be merged to the tail though?
> > 
> > I guess you are referring to the page shuffling. If that is the case
> > then this is an integral part of the allocator for a reason and it is
> > very well obvious in the code including the consequences. I do not
> > really like an idea of hiding similar constrains behind a generic
> > looking feature which is completely detached from the allocator and so
> > any future change of the allocator might subtly break it.
> 
> I don't necessary follow why shuffling is more integral to page allocator
> than reporting would be. It's next to shutffle.c under mm/ and integrated
> in a simillar way.

The main difference from my understanding is that the page reporting is
a more generic looking feature which might grow different users over
time yet there is a hardcoded set of restrictions to the allocator. Page
shuffling is an integral part of the allocator without any other
visibility outside.

Nitesh Narayan Lal Sept. 12, 2019, noon UTC | #36

On 9/12/19 3:47 AM, David Hildenbrand wrote:
> On 12.09.19 09:16, Michal Hocko wrote:
>> On Wed 11-09-19 18:09:18, David Hildenbrand wrote:
>>> On 11.09.19 15:51, Michal Hocko wrote:
>>>> On Wed 11-09-19 15:20:02, Michal Hocko wrote:
>>>> [...]
>>>>>> 4. Continuously report, not the "one time report everything" approach.
>>>>> So you mean the allocator reporting this rather than an external code to
>>>>> poll right? I do not know, how much this is nice to have than must have?
>>>> Another idea that I haven't really thought through so it might turned
>>>> out to be completely bogus but let's try anyway. Your "report everything"
>>>> just made me look and realize that free_pages_prepare already performs
>>>> stuff that actually does something similar yet unrelated.
>>>>
>>>> We do report to special page poisoning, zeroying or
>>>> CONFIG_DEBUG_PAGEALLOC to unmap the address from the kernel address
>>>> space. This sounds like something fitting your model no?
>>>>
>>> AFAIKS, the poisoning/unmapping is done whenever a page is freed. I
>>> don't quite see yet how that would help to remember if a page was
>>> already reported.
>> Do you still have to differ that state when each page is reported?
> Ah, very good point. I can see that the reason for this was not
> discussed in this thread so far. (Alexander, Nitesh, please correct me
> if I am wrong). It's buried in the long history of free page
> hinting/reporting.
>
> Some early patch sets tried to report during every free synchronously.
> Free a page, report them to the hypervisor. This resulted in some issues
> (especially, locking-related and the virtio + the hypervisor being
> involved, resulting in unpredictable delays, quite some overhead ...).
> It was no good.

+1
If I remember correctly then Alexander had posted a patch-set
prior to this series where he was reporting every page of a fixed
order from __free_one_page(). But as you said it will be costly as
it will involve one hypercall per page of reporting_order.

>
> One design decision then was to not report single pages, but a bunch of
> pages at once. This made it necessary to "remember" the pages to be
> reported and to temporarily block them from getting allocated while
> reporting.

Until my v7 posting [1] I was doing this. We did not proceed with
this as blocking allocation was not recommended for reporting.

>
> Nitesh implemented (at least) two "capture PFNs of free pages in an
> array when freeing" approaches. One being synchronous from the freeing
> CPU once the list was full (having similar issues as plain synchronous
> reporting) and one being asynchronous by a separate thread (which solved
> many locking issues).

One issue with asynchronous + array approach was that it could have lead
to false OOMs due to several pages being isolated at the same time.

>
> Turned out the a simple array can quickly lead to us having to drop
> "reports" to the hypervisor because the array is full and the reporting
> thread was not able to keep up. Not good as well. Especially, if some
> process frees a lot of memory this can happen quickly and Nitesh wa
> sable to trigger this scenario frequently.

+1

>
> Finally, Nitesh decided to use the bitmap instead to keep track of pages
> to report. I'd like to note that this approach could still be combined
> with an "array of potentially free PFNs". Only when the array/circular
> buffer runs out of entries ("reporting thread cannot keep up"), we would
> have to go back to scanning the bitmap.

I will have to think about it.

> That was also the point where Alexander decided to look into integrating
> tracking/handling reported/unreported pages directly in the buddy.
>
>>> After reporting the page we would have to switch some
>>> state (Nitesh: bitmap bit, Alexander: page flag) to identify that.
>> Yes, you can either store the state somewhere.
>>
>>> Of course, we could map the page and treat that as "the state" when we
>>> reported it, but I am not sure that's such a good idea :)
>>>
>>> As always, I might be very wrong ...
>> I still do not fully understand the usecase so I might be equally wrong.
>> My thinking is along these lines. Why should you scan free pages when
>> you can effectively capture each freed page? If you go one step further
>> then post_alloc_hook would be the counterpart to know that your page has
>> been allocated.
> I'd like to note that Nitesh's patch set contains the following hunk,
> which is roughly what you were thinking :)
>
>
> -static inline void __free_one_page(struct page *page,
> +inline void __free_one_page(struct page *page,
>  		unsigned long pfn,
>  		struct zone *zone, unsigned int order,
> -		int migratetype)
> +		int migratetype, bool hint)
>  {
>  	unsigned long combined_pfn;
>  	unsigned long uninitialized_var(buddy_pfn);
> @@ -980,7 +981,8 @@ static inline void __free_one_page(struct page *page,
>  				migratetype);
>  	else
>  		add_to_free_area(page, &zone->free_area[order], migratetype);
> -
> +	if (hint)
> +		page_hinting_enqueue(page, order);
>  }
>
>
> (ignore the hint parameter, when he would switch to a isolate vs.
> alloc/free, that can go away and all we left is the enqueue part)

Precisely.
Although, there would be a scenario where the allocation will
take place for a page whose order would be < REPORTING_ORDER.
In that case, if I decide to ignore all the remaining pages and clear
the previously head free page bit, I might end
up losing the reporting opportunity.

But I can certainly look into this.

>
>
> Inside that callback we can remember the pages any way we want. Right
> now in a bitmap. Maybe later in a array + bitmap (as discussed above).
> Another idea I had was to simply go over all pages and report them when
> running into this "array full" condition. But I am not yet sure about
> the performance implications on rather large machines. So the bitmap
> idea might have some other limitations but seems to do its job.

That's correct, I was actually trying to come up with a basic framework.
Which is acceptable in terms of benefits and performance and that can fit into
most of the use-cases (if not all).
After which my plan was to further optimize it.

>
> Hoe that makes things clearer and am not missing something.

Thanks for explaining.

>

Alexander Duyck Sept. 12, 2019, 3:42 p.m. UTC | #37

On Thu, 2019-09-12 at 11:19 +0200, Michal Hocko wrote:
> On Wed 11-09-19 08:12:03, Alexander Duyck wrote:
> > On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <[e-mail]> wrote:
> > > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > > [...]
> > > > We don't put any limitations on the allocator other then that it needs to
> > > > clean up the metadata on allocation, and that it cannot allocate a page
> > > > that is in the process of being reported since we pulled it from the
> > > > free_list. If the page is a "Reported" page then it decrements the
> > > > reported_pages count for the free_area and makes sure the page doesn't
> > > > exist in the "Boundary" array pointer value, if it does it moves the
> > > > "Boundary" since it is pulling the page.
> > > 
> > > This is still a non-trivial limitation on the page allocation from an
> > > external code IMHO. I cannot give any explicit reason why an ordering on
> > > the free list might matter (well except for page shuffling which uses it
> > > to make physical memory pattern allocation more random) but the
> > > architecture seems hacky and dubious to be honest. It shoulds like the
> > > whole interface has been developed around a very particular and single
> > > purpose optimization.
> > 
> > How is this any different then the code that moves a page that will
> > likely be merged to the tail though?
> 
> I guess you are referring to the page shuffling. If that is the case
> then this is an integral part of the allocator for a reason and it is
> very well obvious in the code including the consequences. I do not
> really like an idea of hiding similar constrains behind a generic
> looking feature which is completely detached from the allocator and so
> any future change of the allocator might subtly break it.
> 
> > In our case the "Reported" page is likely going to be much more
> > expensive to allocate and use then a standard page because it will be
> > faulted back in. In such a case wouldn't it make sense for us to want
> > to keep the pages that don't require faults ahead of those pages in
> > the free_list so that they are more likely to be allocated?
> 
> OK, I was suspecting this would pop out. And this is exactly why I
> didn't like an idea of an external code imposing a non obvious constrains
> to the allocator. You simply cannot count with any ordering with the
> page allocator. We used to distinguish cache hot/cold pages in the past
> and pushed pages to the specific end of the free list but that has been
> removed. There are other potential changes like that possible. Shuffling
> is a good recent example.
> 
> Anyway I am not a maintainer of this code. I would really like to hear
> opinions from Mel and Vlastimil here (now CCed - the thread starts
> http://lkml.kernel.org/r/[e-mail].

One alternative I could do if we are wanting to make things more obvious
would be to add yet another add_to_free_list_XXX function that would be
used specifically for reported pages. The only real requirement I have is
that we have to insert reported pages such that we generate a continuous
block without interleaving non-reported pages in between. So as long as
reported pages are always inserted at the boundary/iterator when we are
actively reporting on a section then I can guarantee the list won't have
gaps formed.

Also as far as the concerns about this being an external user, one thing I
can do is break up the headers a bit and define an internal header in mm/
that defines all the items used by the page allocator, and another in
include/linux/ that defines what is used by devices when receiving the
notifications. It would then help to reduce the likelihood of an outside
entity messing with the page allocator too much.

Mel Gorman Sept. 12, 2019, 4:35 p.m. UTC | #38

On Thu, Sep 12, 2019 at 11:19:25AM +0200, Michal Hocko wrote:
> On Wed 11-09-19 08:12:03, Alexander Duyck wrote:
> > On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <[e-mail]> wrote:
> > >
> > > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > > [...]
> > > > We don't put any limitations on the allocator other then that it needs to
> > > > clean up the metadata on allocation, and that it cannot allocate a page
> > > > that is in the process of being reported since we pulled it from the
> > > > free_list. If the page is a "Reported" page then it decrements the
> > > > reported_pages count for the free_area and makes sure the page doesn't
> > > > exist in the "Boundary" array pointer value, if it does it moves the
> > > > "Boundary" since it is pulling the page.
> > >
> > > This is still a non-trivial limitation on the page allocation from an
> > > external code IMHO. I cannot give any explicit reason why an ordering on
> > > the free list might matter (well except for page shuffling which uses it
> > > to make physical memory pattern allocation more random) but the
> > > architecture seems hacky and dubious to be honest. It shoulds like the
> > > whole interface has been developed around a very particular and single
> > > purpose optimization.
> > 
> > How is this any different then the code that moves a page that will
> > likely be merged to the tail though?
> 
> I guess you are referring to the page shuffling. If that is the case
> then this is an integral part of the allocator for a reason and it is
> very well obvious in the code including the consequences. I do not
> really like an idea of hiding similar constrains behind a generic
> looking feature which is completely detached from the allocator and so
> any future change of the allocator might subtly break it.
> 

It's not just that, compaction pokes into the free_area information as
well and directly takes pages from the free list without going through
the page allocator itself. It assumes that a free page is a free page
and only takes the zone and migratetype into account.

> > In our case the "Reported" page is likely going to be much more
> > expensive to allocate and use then a standard page because it will be
> > faulted back in. In such a case wouldn't it make sense for us to want
> > to keep the pages that don't require faults ahead of those pages in
> > the free_list so that they are more likely to be allocated?
> 
> OK, I was suspecting this would pop out. And this is exactly why I
> didn't like an idea of an external code imposing a non obvious constrains
> to the allocator. You simply cannot count with any ordering with the
> page allocator.

Indeed not. It can be arbitrary and compaction can interfere with the
ordering as well. While in theory that could be addressed by always
going through an interface maintained by the page allocator, it would be
tricky to test the virtio case in particular.

> We used to distinguish cache hot/cold pages in the past
> and pushed pages to the specific end of the free list but that has been
> removed.

That was always best effort too, not a hard guarantee. It was eventually
removed as the cost of figuring out the ordering exceeded the benefit.

> There are other potential changes like that possible. Shuffling
> is a good recent example.
> 
> Anyway I am not a maintainer of this code. I would really like to hear
> opinions from Mel and Vlastimil here (now CCed - the thread starts
> http://lkml.kernel.org/r/[e-mail].

I worry that poking too much into the internal state of the allocator
will be fragile long-term. There is the arch alloc/free hooks but they
are typically about protections only and does not interfere with the
internal state of the allocator. Compaction pokes in as well but once
the page is off the free list, the page allocator no longer cares so
again there is on interference with the internal state. If the state is
interefered with externally, it becomes unclear what happens if things
like page merging is deferred in a way the allocator cannot control as
high-order allocation requests may fail for example. For THP, it would
not matter but failed allocation reports when pages are on the freelist,
but unsuitable for allocation because of the reported state, would be
hard to debug. Similarly, latency issues due to a reported page being
picked for allocation but requiring communication with the hypervisor
will be difficult to debug and atomic allocations may fail entirely.
Finally, if merging was broken for reported/unreported pages, it could
be a long time before such bugs were fixed.

That's a lot of caveats to optimise communication about unused free
pages to the allocator. I didn't read the patches particularly carefully
but it was not clear why a best effort was not made to track free pages
and if the metadata maintenance for that fills then do exhaustive
searches for remaining pages. It might be difficult to stabilise that as
the metadata may overflow again while the exhaustive search takes place.
Much would depend on the frequency that pages are entering/leaving
reported state.

Alexander Duyck Sept. 12, 2019, 5:48 p.m. UTC | #39

On Thu, 2019-09-12 at 17:35 +0100, Mel Gorman wrote:
> On Thu, Sep 12, 2019 at 11:19:25AM +0200, Michal Hocko wrote:
> > On Wed 11-09-19 08:12:03, Alexander Duyck wrote:
> > > On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <[e-mail]> wrote:
> > > > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > > > [...]
> > > > > We don't put any limitations on the allocator other then that it needs to
> > > > > clean up the metadata on allocation, and that it cannot allocate a page
> > > > > that is in the process of being reported since we pulled it from the
> > > > > free_list. If the page is a "Reported" page then it decrements the
> > > > > reported_pages count for the free_area and makes sure the page doesn't
> > > > > exist in the "Boundary" array pointer value, if it does it moves the
> > > > > "Boundary" since it is pulling the page.
> > > > 
> > > > This is still a non-trivial limitation on the page allocation from an
> > > > external code IMHO. I cannot give any explicit reason why an ordering on
> > > > the free list might matter (well except for page shuffling which uses it
> > > > to make physical memory pattern allocation more random) but the
> > > > architecture seems hacky and dubious to be honest. It shoulds like the
> > > > whole interface has been developed around a very particular and single
> > > > purpose optimization.
> > > 
> > > How is this any different then the code that moves a page that will
> > > likely be merged to the tail though?
> > 
> > I guess you are referring to the page shuffling. If that is the case
> > then this is an integral part of the allocator for a reason and it is
> > very well obvious in the code including the consequences. I do not
> > really like an idea of hiding similar constrains behind a generic
> > looking feature which is completely detached from the allocator and so
> > any future change of the allocator might subtly break it.
> > 
> 
> It's not just that, compaction pokes into the free_area information as
> well and directly takes pages from the free list without going through
> the page allocator itself. It assumes that a free page is a free page
> and only takes the zone and migratetype into account.

Pulling pages out at random isn't an issue as long as the boundary pointer
gets pushed back. However the list tumbling with the
move_freelist_head/tail would be much more problematic for me since it is
essentially shuffling the list and will cause reported pages to be
shuffled in with non-reported ones.

> > > In our case the "Reported" page is likely going to be much more
> > > expensive to allocate and use then a standard page because it will be
> > > faulted back in. In such a case wouldn't it make sense for us to want
> > > to keep the pages that don't require faults ahead of those pages in
> > > the free_list so that they are more likely to be allocated?
> > 
> > OK, I was suspecting this would pop out. And this is exactly why I
> > didn't like an idea of an external code imposing a non obvious constrains
> > to the allocator. You simply cannot count with any ordering with the
> > page allocator.
> 
> Indeed not. It can be arbitrary and compaction can interfere with the
> ordering as well. While in theory that could be addressed by always
> going through an interface maintained by the page allocator, it would be
> tricky to test the virtio case in particular.
> 
> > We used to distinguish cache hot/cold pages in the past
> > and pushed pages to the specific end of the free list but that has been
> > removed.
> 
> That was always best effort too, not a hard guarantee. It was eventually
> removed as the cost of figuring out the ordering exceeded the benefit.
> 
> > There are other potential changes like that possible. Shuffling
> > is a good recent example.
> > 
> > Anyway I am not a maintainer of this code. I would really like to hear
> > opinions from Mel and Vlastimil here (now CCed - the thread starts
> > http://lkml.kernel.org/r/[e-mail].
> 
> I worry that poking too much into the internal state of the allocator
> will be fragile long-term. There is the arch alloc/free hooks but they
> are typically about protections only and does not interfere with the
> internal state of the allocator. Compaction pokes in as well but once
> the page is off the free list, the page allocator no longer cares so
> again there is on interference with the internal state. If the state is
> interefered with externally, it becomes unclear what happens if things
> like page merging is deferred in a way the allocator cannot control as
> high-order allocation requests may fail for example. For THP, it would
> not matter but failed allocation reports when pages are on the freelist,
> but unsuitable for allocation because of the reported state, would be
> hard to debug. Similarly, latency issues due to a reported page being
> picked for allocation but requiring communication with the hypervisor
> will be difficult to debug and atomic allocations may fail entirely.
> Finally, if merging was broken for reported/unreported pages, it could
> be a long time before such bugs were fixed.

We weren't preventing allocations off of the list other then when the
pages were actually off the list and being reported. So a reported page
could still be allocated normally.

As far as state there were only two things that were really being tracked
with the Reported flag. Basically when we cleared it we needed to make
sure the boundary pointer for the freelist was checked so we could push it
back if needed, and the count for the reported pages was decremented. All
the page->index was providing was an index into the boundary array so we
could find the pointer for that specific free_list.

> That's a lot of caveats to optimise communication about unused free
> pages to the allocator. I didn't read the patches particularly carefully
> but it was not clear why a best effort was not made to track free pages
> and if the metadata maintenance for that fills then do exhaustive
> searches for remaining pages. It might be difficult to stabilise that as
> the metadata may overflow again while the exhaustive search takes place.
> Much would depend on the frequency that pages are entering/leaving
> reported state.

What I was trying to avoid is having to perform an exhaustive walk of the
free_list. I was using boundary as an iterator. Since we have to hold the
zone->lock while pulling pages I wanted to keep the critical section as
small and fast as possible.

It seems like you were somewhat accomplishing that in the compaction code
by using the move_freelist_head/tail calls to basically roll over the list
as you are working through it. Maybe I will look to see just how expensive
it would be to do something similar as that would at least partially
reduce the cost.