[virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
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 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
[virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
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 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. - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
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
>
[virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
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, >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
[virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
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 ... -- Thanks, David / dhildenb - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
>> 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. -- Thanks, David / dhildenb - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
On Wed, Sep 11, 2019 at 4:36 AM 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. 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.w...@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_tfk7e5ar1f...@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. - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
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.w...@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
[virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
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.w...@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.
--
Thanks
Nitesh
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
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.w...@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
[virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
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.w...@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 -- Thanks Nitesh - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
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.w...@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. -- Thanks, David / dhildenb - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
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.w...@intel.com > > -- > Michal Hocko > SUSE Labs Linus nacked that one. He thinks invoking callbacks with lots of internal mm locks is too fragile. - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
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.w...@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 -- Thanks, David / dhildenb - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
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.du...@gmail.com) wrote: On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko wrote: > > On Tue 10-09-19 07:42:43, Alexander Duyck wrote: >> On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko 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 Date: Thu Apr 7 10:43:25 2011 -0700
Re: [virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
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.du...@gmail.com) wrote: > >> On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko wrote: > >>> > >>> On Tue 10-09-19 07:42:43, Alexander Duyck wrote: > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko 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
[virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
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. - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
On 10.09.19 18:18, Dr. David Alan Gilbert wrote: > * Alexander Duyck (alexander.du...@gmail.com) wrote: >> On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko wrote: >>> >>> On Tue 10-09-19 07:42:43, Alexander Duyck wrote: On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko 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 -- Thanks, David / dhildenb - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
Re: [virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
* Alexander Duyck (alexander.du...@gmail.com) wrote: > On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko wrote: > > > > On Tue 10-09-19 07:42:43, Alexander Duyck wrote: > > > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko 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-unsubscr...@lists.oasis-open.org > For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko wrote: > > On Tue 10-09-19 07:42:43, Alexander Duyck wrote: > > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko 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. - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko 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. - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
