Message ID | 20190907172225.10910.34302.stgit@localhost.localdomain (mailing list archive) |
---|---|
Headers | show |
Series | stg mail -e --version=v9 \ | expand |
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 <alexander.duyck@gmail.com> 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/20190530215223.13974.22445.stgit@localhost.localdomain/ > 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/20190619222922.1231.27432.stgit@localhost.localdomain/ > 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/20190724165158.6685.87228.stgit@localhost.localdomain/ > 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/20190801222158.22190.96964.stgit@localhost.localdomain/ > 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/20190807224037.6891.53512.stgit@localhost.localdomain/ > 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/20190812213158.22097.30576.stgit@localhost.localdomain/ > 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/20190821145806.20926.22448.stgit@localhost.localdomain/ > 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/20190904150920.13848.32271.stgit@localhost.localdomain/ > 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/20190906145213.32552.30160.stgit@localhost.localdomain/ > 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 > > --
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.
On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> 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.
On Tue 10-09-19 07:42:43, Alexander Duyck wrote: > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> 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?
On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <mhocko@kernel.org> wrote: > > On Tue 10-09-19 07:42:43, Alexander Duyck wrote: > > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> 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.
* Alexander Duyck (alexander.duyck@gmail.com) wrote: > On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <mhocko@kernel.org> wrote: > > > > On Tue 10-09-19 07:42:43, Alexander Duyck wrote: > > > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> 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: virtio-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
On 10.09.19 18:18, Dr. David Alan Gilbert wrote: > * Alexander Duyck (alexander.duyck@gmail.com) wrote: >> On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <mhocko@kernel.org> wrote: >>> >>> On Tue 10-09-19 07:42:43, Alexander Duyck wrote: >>>> On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> 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
On Tue 10-09-19 09:05:43, Alexander Duyck wrote: > On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <mhocko@kernel.org> wrote: > > > > On Tue 10-09-19 07:42:43, Alexander Duyck wrote: > > > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> 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?
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.
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.
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 <mhocko@kernel.org> wrote: > > > On Tue 10-09-19 07:42:43, Alexander Duyck wrote: > > > > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> 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.
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 (alexander.duyck@gmail.com) wrote: > >> On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <mhocko@kernel.org> wrote: > >>> > >>> On Tue 10-09-19 07:42:43, Alexander Duyck wrote: > >>>> On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> 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
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 (alexander.duyck@gmail.com) wrote: >>>> On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <mhocko@kernel.org> wrote: >>>>> >>>>> On Tue 10-09-19 07:42:43, Alexander Duyck wrote: >>>>>> On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> 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 <dave@linux.vnet.ibm.com> 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
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/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
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/1502940416-42944-5-git-send-email-wei.w.wang@intel.com > 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
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/1502940416-42944-5-git-send-email-wei.w.wang@intel.com > > -- > Michal Hocko > SUSE Labs Linus nacked that one. He thinks invoking callbacks with lots of internal mm locks is too fragile.
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/1502940416-42944-5-git-send-email-wei.w.wang@intel.com > > 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.
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/1502940416-42944-5-git-send-email-wei.w.wang@intel.com > > > > 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.
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/1502940416-42944-5-git-send-email-wei.w.wang@intel.com >>> >>> 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.
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/1502940416-42944-5-git-send-email-wei.w.wang@intel.com > >>> > >>> 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.
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/1502940416-42944-5-git-send-email-wei.w.wang@intel.com >>>> 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
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/1502940416-42944-5-git-send-email-wei.w.wang@intel.com >>>>> >>>>> 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.
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/1502940416-42944-5-git-send-email-wei.w.wang@intel.com >>>>> 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.
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/1502940416-42944-5-git-send-email-wei.w.wang@intel.com > >>>>> > >>>>> 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?
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?
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/1502940416-42944-5-git-send-email-wei.w.wang@intel.com >>>>>>> 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.
On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <mhocko@kernel.org> 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/1502940416-42944-5-git-send-email-wei.w.wang@intel.com 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/CA+55aFzqj8wxXnHAdUTiOomipgFONVbqKMjL_tfk7e5ar1FziQ@mail.gmail.com/ 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.
>> 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.
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 ...
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.
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.
On Wed 11-09-19 08:12:03, Alexander Duyck wrote: > On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <mhocko@kernel.org> 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/20190907172225.10910.34302.stgit@localhost.localdomain.
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!
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 <mhocko@kernel.org> 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.
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 <mhocko@kernel.org> 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.
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. >
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 <mhocko@kernel.org> 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/20190907172225.10910.34302.stgit@localhost.localdomain. 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.
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 <mhocko@kernel.org> 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/20190907172225.10910.34302.stgit@localhost.localdomain. 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.
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 <mhocko@kernel.org> 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/20190907172225.10910.34302.stgit@localhost.localdomain. > > 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.