[virtio-dev] Re: [RFC][Patch v12 1/2] mm: page_reporting: core infrastructure
On 10/10/19 4:36 PM, Alexander Duyck wrote:
> On Mon, Aug 12, 2019 at 6:13 AM Nitesh Narayan Lal wrote:
>
>
>> +static int process_free_page(struct page *page,
>> +struct page_reporting_config *phconf, int count)
>> +{
>> + int mt, order, ret = 0;
>> +
>> + mt = get_pageblock_migratetype(page);
>> + order = page_private(page);
>> + ret = __isolate_free_page(page, order);
>> +
>> + if (ret) {
>> + /*
>> +* Preserving order and migratetype for reuse while
>> +* releasing the pages back to the buddy.
>> +*/
>> + set_pageblock_migratetype(page, mt);
>> + set_page_private(page, order);
>> +
>> + sg_set_page(>sg[count++], page,
>> + PAGE_SIZE << order, 0);
>> + }
>> +
>> + return count;
>> +}
>> +
>> +/**
>> + * scan_zone_bitmap - scans the bitmap for the requested zone.
>> + * @phconf: page reporting configuration object initialized by the backend.
>> + * @zone: zone for which page reporting is requested.
>> + *
>> + * For every page marked in the bitmap it checks if it is still free if so
>> it
>> + * isolates and adds them to a scatterlist. As soon as the number of
>> isolated
>> + * pages reach the threshold set by the backend, they are reported to the
>> + * hypervisor by the backend. Once the hypervisor responds after processing
>> + * they are returned back to the buddy for reuse.
>> + */
>> +static void scan_zone_bitmap(struct page_reporting_config *phconf,
>> +struct zone *zone)
>> +{
>> + unsigned long setbit;
>> + struct page *page;
>> + int count = 0;
>> +
>> + sg_init_table(phconf->sg, phconf->max_pages);
>> +
>> + for_each_set_bit(setbit, zone->bitmap, zone->nbits) {
>> + /* Process only if the page is still online */
>> + page = pfn_to_online_page((setbit <<
>> PAGE_REPORTING_MIN_ORDER) +
>> + zone->base_pfn);
>> + if (!page)
>> + continue;
>> +
>> + spin_lock(>lock);
>> +
>> + /* Ensure page is still free and can be processed */
>> + if (PageBuddy(page) && page_private(page) >=
>> + PAGE_REPORTING_MIN_ORDER)
>> + count = process_free_page(page, phconf, count);
>> +
>> + spin_unlock(>lock);
>> + /* Page has been processed, adjust its bit and zone counter
>> */
>> + clear_bit(setbit, zone->bitmap);
>> + atomic_dec(>free_pages);
>> +
>> + if (count == phconf->max_pages) {
>> + /* Report isolated pages to the hypervisor */
>> + phconf->report(phconf, count);
>> +
>> + /* Return processed pages back to the buddy */
>> + return_isolated_page(zone, phconf);
>> +
>> + /* Reset for next reporting */
>> + sg_init_table(phconf->sg, phconf->max_pages);
>> + count = 0;
>> + }
>> + }
>> + /*
>> +* If the number of isolated pages does not meet the max_pages
>> +* threshold, we would still prefer to report them as we have already
>> +* isolated them.
>> +*/
>> + if (count) {
>> + sg_mark_end(>sg[count - 1]);
>> + phconf->report(phconf, count);
>> +
>> + return_isolated_page(zone, phconf);
>> + }
>> +}
>> +
> So one thing that occurred to me is that this code is missing checks
> so that it doesn't try to hint isolated pages. With the bitmap
> approach you need an additional check so that you aren't pulling
> isolated pages out and reporting them.
I think you mean that we should not report pages of type MIGRATE_ISOLATE.
The current code on which I am working, I have added the
is_migrate_isolate_page() check
to ensure that I am not processing these pages.
--
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 v11 0/6] mm / virtio: Provide support for unused page reporting
On 10/9/19 12:50 PM, Alexander Duyck wrote:
> On Wed, 2019-10-09 at 12:25 -0400, Nitesh Narayan Lal wrote:
>> On 10/7/19 1:20 PM, Alexander Duyck wrote:
>>> On Mon, Oct 7, 2019 at 10:07 AM Nitesh Narayan Lal
>>> wrote:
>>>> On 10/7/19 12:27 PM, Alexander Duyck wrote:
>>>>> On Mon, 2019-10-07 at 12:19 -0400, Nitesh Narayan Lal wrote:
>>>>>> On 10/7/19 11:33 AM, Alexander Duyck wrote:
>>>>>>> On Mon, 2019-10-07 at 08:29 -0400, Nitesh Narayan Lal wrote:
>>>>>>>> On 10/2/19 10:25 AM, Alexander Duyck wrote:
>>>
>>>
>>>>>>>> page_reporting.c change:
>>>>>>>> @@ -101,8 +101,12 @@ static void scan_zone_bitmap(struct
>>>>>>>> page_reporting_config
>>>>>>>> *phconf,
>>>>>>>> /* Process only if the page is still online */
>>>>>>>> page = pfn_to_online_page((setbit <<
>>>>>>>> PAGE_REPORTING_MIN_ORDER) +
>>>>>>>> zone->base_pfn);
>>>>>>>> - if (!page)
>>>>>>>> + if (!page || !PageBuddy(page)) {
>>>>>>>> + clear_bit(setbit, zone->bitmap);
>>>>>>>> + atomic_dec(>free_pages);
>>>>>>>> continue;
>>>>>>>> + }
>>>>>>>>
>>>>>>> I suspect the zone->free_pages is going to be expensive for you to deal
>>>>>>> with. It is a global atomic value and is going to have the cacheline
>>>>>>> bouncing that it is contained in. As a result thinks like setting the
>>>>>>> bitmap with be more expensive as every tome a CPU increments free_pages
>>>>>>> it
>>>>>>> will likely have to take the cache line containing the bitmap pointer as
>>>>>>> well.
>>>>>> I see I will have to explore this more. I am wondering if there is a way
>>>>>> to
>>>>>> measure this If its effect is not visible in will-it-scale/page_fault1.
>>>>>> If
>>>>>> there is a noticeable amount of degradation, I will have to address this.
>>>>> If nothing else you might look at seeing if you can split up the
>>>>> structures so that the bitmap and nr_bits is in a different region
>>>>> somewhere since those are read-mostly values.
>>>> ok, I will try to understand the issue and your suggestion.
>>>> Thank you for bringing this up.
>>>>
>>>>> Also you are now updating the bitmap and free_pages both inside and
>>>>> outside of the zone lock so that will likely have some impact.
>>>> So as per your previous suggestion, I have made the bitmap structure
>>>> object as a rcu protected pointer. So we are safe from that side.
>>>> The other downside which I can think of is a race where one page
>>>> trying to increment free_pages and other trying to decrements it.
>>>> However, being an atomic variable that should not be a problem.
>>>> Did I miss anything?
>>> I'm not so much worried about a race as the cache line bouncing
>>> effect. Basically your notifier combined within this hinting thread
>>> will likely result in more time spent by the thread that holds the
>>> lock since it will be trying to access the bitmap to set the bit and
>>> the free_pages to report the bit, but at the same time you will have
>>> this thread clearing bits and decrementing the free_pages values.
>>>
>>> One thing you could consider in your worker thread would be to do
>>> reallocate and replace the bitmap every time you plan to walk it. By
>>> doing that you would avoid the cacheline bouncing on the bitmap since
>>> you would only have to read it, and you would no longer have another
>>> thread dirtying it. You could essentially reset the free_pages at the
>>> same time you replace the bitmap. It would need to all happen with the
>>> zone lock held though when you swap it out.
>> If I am not mistaken then from what you are suggesting, I will have to hold
>> the zone lock for the entire duration of swap & scan which would be costly if
>> the bitmap is large, isn't? Also, we might end up missing free pages that are
>> getting
>> freed whi
[virtio-dev] Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting
On 10/7/19 1:20 PM, Alexander Duyck wrote:
> On Mon, Oct 7, 2019 at 10:07 AM Nitesh Narayan Lal wrote:
>>
>> On 10/7/19 12:27 PM, Alexander Duyck wrote:
>>> On Mon, 2019-10-07 at 12:19 -0400, Nitesh Narayan Lal wrote:
>>>> On 10/7/19 11:33 AM, Alexander Duyck wrote:
>>>>> On Mon, 2019-10-07 at 08:29 -0400, Nitesh Narayan Lal wrote:
>>>>>> On 10/2/19 10:25 AM, Alexander Duyck wrote:
>
>
>>>>>> page_reporting.c change:
>>>>>> @@ -101,8 +101,12 @@ static void scan_zone_bitmap(struct
>>>>>> page_reporting_config
>>>>>> *phconf,
>>>>>> /* Process only if the page is still online */
>>>>>> page = pfn_to_online_page((setbit <<
>>>>>> PAGE_REPORTING_MIN_ORDER) +
>>>>>> zone->base_pfn);
>>>>>> - if (!page)
>>>>>> + if (!page || !PageBuddy(page)) {
>>>>>> + clear_bit(setbit, zone->bitmap);
>>>>>> + atomic_dec(>free_pages);
>>>>>> continue;
>>>>>> + }
>>>>>>
>>>>> I suspect the zone->free_pages is going to be expensive for you to deal
>>>>> with. It is a global atomic value and is going to have the cacheline
>>>>> bouncing that it is contained in. As a result thinks like setting the
>>>>> bitmap with be more expensive as every tome a CPU increments free_pages it
>>>>> will likely have to take the cache line containing the bitmap pointer as
>>>>> well.
>>>> I see I will have to explore this more. I am wondering if there is a way to
>>>> measure this If its effect is not visible in will-it-scale/page_fault1. If
>>>> there is a noticeable amount of degradation, I will have to address this.
>>> If nothing else you might look at seeing if you can split up the
>>> structures so that the bitmap and nr_bits is in a different region
>>> somewhere since those are read-mostly values.
>> ok, I will try to understand the issue and your suggestion.
>> Thank you for bringing this up.
>>
>>> Also you are now updating the bitmap and free_pages both inside and
>>> outside of the zone lock so that will likely have some impact.
>> So as per your previous suggestion, I have made the bitmap structure
>> object as a rcu protected pointer. So we are safe from that side.
>> The other downside which I can think of is a race where one page
>> trying to increment free_pages and other trying to decrements it.
>> However, being an atomic variable that should not be a problem.
>> Did I miss anything?
> I'm not so much worried about a race as the cache line bouncing
> effect. Basically your notifier combined within this hinting thread
> will likely result in more time spent by the thread that holds the
> lock since it will be trying to access the bitmap to set the bit and
> the free_pages to report the bit, but at the same time you will have
> this thread clearing bits and decrementing the free_pages values.
>
> One thing you could consider in your worker thread would be to do
> reallocate and replace the bitmap every time you plan to walk it. By
> doing that you would avoid the cacheline bouncing on the bitmap since
> you would only have to read it, and you would no longer have another
> thread dirtying it. You could essentially reset the free_pages at the
> same time you replace the bitmap. It would need to all happen with the
> zone lock held though when you swap it out.
If I am not mistaken then from what you are suggesting, I will have to hold
the zone lock for the entire duration of swap & scan which would be costly if
the bitmap is large, isn't? Also, we might end up missing free pages that are
getting
freed while we are scanning.
As far as free_pages count is concerned, I am thinking if I should
replace it with zone->free_area[REPORTING_ORDER].nr_free which is already there
(I still need to explore this in a bit more depth).
>
> - Alex
--
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 v11 0/6] mm / virtio: Provide support for unused page reporting
On 10/7/19 1:06 PM, Nitesh Narayan Lal wrote: [...] >> So what was the size of your guest? One thing that just occurred to me is >> that you might be running a much smaller guest than I was. > I am running a 30 GB guest. > >>>> If so I would have expected a much higher difference versus >>>> baseline as zeroing/faulting the pages in the host gets expensive fairly >>>> quick. What is the host kernel you are running your test on? I'm just >>>> wondering if there is some additional overhead currently limiting your >>>> setup. My host kernel was just the same kernel I was running in the guest, >>>> just built without the patches applied. >>> Right now I have a different host-kernel. I can install the same kernel to >>> the >>> host as well and see if that changes anything. >> The host kernel will have a fairly significant impact as I recall. For >> example running a stock CentOS kernel lowered the performance compared to >> running a linux-next kernel. As a result the numbers looked better since >> the overall baseline was lower to begin with as the host OS was >> introducing additional overhead. > I see in that case I will try by installing the same guest kernel > to the host as well. As per your suggestion, I tried replacing the host kernel with an upstream kernel without my patches i.e., my host has a kernel built on top of the upstream kernel's master branch which has Sept 23rd commit and the guest has the same kernel for the no-hinting case and same kernel + my patches for the page reporting case. With the changes reported earlier on top of v12, I am not seeing any further degradation (other than what I have previously reported). To be sure that THP is actively used, I did an experiment where I changed the MEMSIZE in the page_fault. On doing so THP usage checked via /proc/meminfo also increased as I expected. In any case, if you find something else please let me know and I will look into it again. I am still looking into your suggestion about cache line bouncing and will reply to it, if I have more questions. [...] -- 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 v11 0/6] mm / virtio: Provide support for unused page reporting
On 10/7/19 12:27 PM, Alexander Duyck wrote: > On Mon, 2019-10-07 at 12:19 -0400, Nitesh Narayan Lal wrote: >> On 10/7/19 11:33 AM, Alexander Duyck wrote: >>> On Mon, 2019-10-07 at 08:29 -0400, Nitesh Narayan Lal wrote: >>>> On 10/2/19 10:25 AM, Alexander Duyck wrote: >>>> >> [...] >>>> You don't have to, I can fix the issues in my patch-set. :) >>>>> Sounds good. Hopefully the stuff I pointed out above helps you to get >>>>> a reproduction and resolve the issues. >>>> So I did observe a significant drop in running my v12 path-set [1] with the >>>> suggested test setup. However, on making certain changes the performance >>>> improved significantly. >>>> >>>> I used my v12 patch-set which I have posted earlier and made the following >>>> changes: >>>> 1. Started reporting only (MAX_ORDER - 1) pages and increased the number of >>>> pages that can be reported at a time to 32 from 16. The intent of >>>> making >>>> these changes was to bring my configuration closer to what Alexander is >>>> using. >>> The increase from 16 to 32 is valid. No point in working in too small of >>> batches. However tightening the order to only test for MAX_ORDER - 1 seems >>> like a step in the wrong direction. The bitmap approach doesn't have much >>> value if it can only work with the highest order page. I realize it is >>> probably necessary in order to make the trick for checking on page_buddy >>> work, but it seems very limiting. >> If using (pageblock_order - 1) is a better way to do this, then I can >> probably >> switch to that. >> I will agree with the fact that we have to make the reporting order >> configurable, atleast to an extent. > I think you mean pageblock_order, not pageblock_order - 1. The problem > with pageblock_order - 1 is that it will have a negative impact on > performance as it would disable THP. Ah, I see. Yes my bad. > >>>> 2. I made an additional change in my bitmap scanning logic to prevent >>>> acquiring >>>> spinlock if the page is already allocated. >>> Again, not a fan. It basically means you can only work with MAX_ORDER - 1 >>> and there will be no ability to work with anything smaller. >>> >>>> Setup: >>>> On a 16 vCPU 30 GB single NUMA guest affined to a single host NUMA, I ran >>>> the >>>> modified will-it-scale/page_fault number of times and calculated the >>>> average >>>> of the number of process and threads launched on the 16th core to compare >>>> the >>>> impact of my patch-set against an unmodified kernel. >>>> >>>> >>>> Conclusion: >>>> %Drop in number of processes launched on 16th vCPU = 1-2% >>>> %Drop in number of threads launched on 16th vCPU = 5-6% >>> These numbers don't make that much sense to me. Are you talking about a >>> fully functioning setup that is madvsing away the memory in the >>> hypervisor? >> Without making this change I was observing a significant amount of drop >> in the number of processes and specifically in the number of threads. >> I did a double-check of the configuration which I have shared. >> I was also observing the "AnonHugePages" via meminfo to check the THP usage. >> Any more suggestions about what else I can do to verify? >> I will be more than happy to try them out. > So what was the size of your guest? One thing that just occurred to me is > that you might be running a much smaller guest than I was. I am running a 30 GB guest. > >>> If so I would have expected a much higher difference versus >>> baseline as zeroing/faulting the pages in the host gets expensive fairly >>> quick. What is the host kernel you are running your test on? I'm just >>> wondering if there is some additional overhead currently limiting your >>> setup. My host kernel was just the same kernel I was running in the guest, >>> just built without the patches applied. >> Right now I have a different host-kernel. I can install the same kernel to >> the >> host as well and see if that changes anything. > The host kernel will have a fairly significant impact as I recall. For > example running a stock CentOS kernel lowered the performance compared to > running a linux-next kernel. As a result the numbers looked better since > the overall baseline was lower to begin with as the host OS was > introducing additional overhead. I see in that case
[virtio-dev] Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting
On 10/7/19 11:33 AM, Alexander Duyck wrote: > On Mon, 2019-10-07 at 08:29 -0400, Nitesh Narayan Lal wrote: >> On 10/2/19 10:25 AM, Alexander Duyck wrote: >> [...] >> You don't have to, I can fix the issues in my patch-set. :) >>> Sounds good. Hopefully the stuff I pointed out above helps you to get >>> a reproduction and resolve the issues. >> So I did observe a significant drop in running my v12 path-set [1] with the >> suggested test setup. However, on making certain changes the performance >> improved significantly. >> >> I used my v12 patch-set which I have posted earlier and made the following >> changes: >> 1. Started reporting only (MAX_ORDER - 1) pages and increased the number of >> pages that can be reported at a time to 32 from 16. The intent of making >> these changes was to bring my configuration closer to what Alexander is >> using. > The increase from 16 to 32 is valid. No point in working in too small of > batches. However tightening the order to only test for MAX_ORDER - 1 seems > like a step in the wrong direction. The bitmap approach doesn't have much > value if it can only work with the highest order page. I realize it is > probably necessary in order to make the trick for checking on page_buddy > work, but it seems very limiting. If using (pageblock_order - 1) is a better way to do this, then I can probably switch to that. I will agree with the fact that we have to make the reporting order configurable, atleast to an extent. > >> 2. I made an additional change in my bitmap scanning logic to prevent >> acquiring >> spinlock if the page is already allocated. > Again, not a fan. It basically means you can only work with MAX_ORDER - 1 > and there will be no ability to work with anything smaller. > >> Setup: >> On a 16 vCPU 30 GB single NUMA guest affined to a single host NUMA, I ran the >> modified will-it-scale/page_fault number of times and calculated the average >> of the number of process and threads launched on the 16th core to compare the >> impact of my patch-set against an unmodified kernel. >> >> >> Conclusion: >> %Drop in number of processes launched on 16th vCPU = 1-2% >> %Drop in number of threads launched on 16th vCPU = 5-6% > These numbers don't make that much sense to me. Are you talking about a > fully functioning setup that is madvsing away the memory in the > hypervisor? Without making this change I was observing a significant amount of drop in the number of processes and specifically in the number of threads. I did a double-check of the configuration which I have shared. I was also observing the "AnonHugePages" via meminfo to check the THP usage. Any more suggestions about what else I can do to verify? I will be more than happy to try them out. > If so I would have expected a much higher difference versus > baseline as zeroing/faulting the pages in the host gets expensive fairly > quick. What is the host kernel you are running your test on? I'm just > wondering if there is some additional overhead currently limiting your > setup. My host kernel was just the same kernel I was running in the guest, > just built without the patches applied. Right now I have a different host-kernel. I can install the same kernel to the host as well and see if that changes anything. > >> Other observations: >> - I also tried running Alexander's latest v11 page-reporting patch set and >> observe a similar amount of average degradation in the number of processes >> and threads. >> - I didn't include the linear component recorded by will-it-scale because for >> some reason it was fluctuating too much even when I was using an unmodified >> kernel. If required I can investigate this further. >> >> Note: If there is a better way to analyze the will-it-scale/page_fault >> results >> then please do let me know. > Honestly I have mostly just focused on the processes performance. In my observation processes seems to be most consistent in general. > There is > usually a fair bit of variability but a pattern forms after a few runs so > you can generally tell if a configuration is an improvement or not. Yeah, that's why I thought of taking the average of 5-6 runs. > >> Other setup details: >> Following are the configurations which I enabled to run my tests: >> - Enabled: CONFIG_SLAB_FREELIST_RANDOM & CONFIG_SHUFFLE_PAGE_ALLOCATOR >> - Set host THP to always >> - Set guest THP to madvise >> - Added the suggested madvise call in page_fault source code. >> @Alexander please let me know if I missed something. > This seems about right. > >> The current state of my v13: >&g
[virtio-dev] Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting
On 10/2/19 10:25 AM, Alexander Duyck wrote:
[...]
>>> My suggestion would be to look at reworking the patch set and
>>> post numbers for my patch set versus the bitmap approach and we can
>>> look at them then.
>> Agreed. However, in order to fix an issue I have to reproduce it first.
> With the tweak I have suggested above it should make it much easier to
> reproduce. Basically all you need is to have the allocation competing
> against hinting. Currently the hinting isn't doing this because the
> allocations are mostly coming out of 4K pages instead of higher order
> ones.
>
> Alternatively you could just make the suggestion I had proposed about
> using spin_lock/unlock_irq in your worker thread and that resolved it
> for me.
>
>>> I would prefer not to spend my time fixing and
>>> tuning a patch set that I am still not convinced is viable.
>> You don't have to, I can fix the issues in my patch-set. :)
> Sounds good. Hopefully the stuff I pointed out above helps you to get
> a reproduction and resolve the issues.
So I did observe a significant drop in running my v12 path-set [1] with the
suggested test setup. However, on making certain changes the performance
improved significantly.
I used my v12 patch-set which I have posted earlier and made the following
changes:
1. Started reporting only (MAX_ORDER - 1) pages and increased the number of
pages that can be reported at a time to 32 from 16. The intent of making
these changes was to bring my configuration closer to what Alexander is
using.
2. I made an additional change in my bitmap scanning logic to prevent acquiring
spinlock if the page is already allocated.
Setup:
On a 16 vCPU 30 GB single NUMA guest affined to a single host NUMA, I ran the
modified will-it-scale/page_fault number of times and calculated the average
of the number of process and threads launched on the 16th core to compare the
impact of my patch-set against an unmodified kernel.
Conclusion:
%Drop in number of processes launched on 16th vCPU = 1-2%
%Drop in number of threads launched on 16th vCPU = 5-6%
Other observations:
- I also tried running Alexander's latest v11 page-reporting patch set and
observe a similar amount of average degradation in the number of processes
and threads.
- I didn't include the linear component recorded by will-it-scale because for
some reason it was fluctuating too much even when I was using an unmodified
kernel. If required I can investigate this further.
Note: If there is a better way to analyze the will-it-scale/page_fault results
then please do let me know.
Other setup details:
Following are the configurations which I enabled to run my tests:
- Enabled: CONFIG_SLAB_FREELIST_RANDOM & CONFIG_SHUFFLE_PAGE_ALLOCATOR
- Set host THP to always
- Set guest THP to madvise
- Added the suggested madvise call in page_fault source code.
@Alexander please let me know if I missed something.
The current state of my v13:
I still have to look into Michal's suggestion of using page-isolation API's
instead of isolating the page. However, I believe at this moment our objective
is to decide with which approach we can proceed and that's why I decided to
post the numbers by making small required changes in v12 instead of posting a
new series.
Following are the changes which I have made on top of my v12:
page_reporting.h change:
-#define PAGE_REPORTING_MIN_ORDER (MAX_ORDER - 2)
-#define PAGE_REPORTING_MAX_PAGES 16
+#define PAGE_REPORTING_MIN_ORDER (MAX_ORDER - 1)
+#define PAGE_REPORTING_MAX_PAGES 32
page_reporting.c change:
@@ -101,8 +101,12 @@ static void scan_zone_bitmap(struct page_reporting_config
*phconf,
/* Process only if the page is still online */
page = pfn_to_online_page((setbit << PAGE_REPORTING_MIN_ORDER) +
zone->base_pfn);
- if (!page)
+ if (!page || !PageBuddy(page)) {
+ clear_bit(setbit, zone->bitmap);
+ atomic_dec(>free_pages);
continue;
+ }
@Alexander in case you decide to give it a try and find different results,
please do let me know.
[1] https://lore.kernel.org/lkml/20190812131235.27244-1-nit...@redhat.com/
--
Thanks
Nitesh
[virtio-dev] Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting
On 10/1/19 4:51 PM, Dave Hansen wrote: > On 10/1/19 1:49 PM, Alexander Duyck wrote: >> So it looks like v12 still has issues. I'm pretty sure you should be using >> spin_lock_irq(), not spin_lock() in page_reporting.c to avoid the >> possibility of an IRQ firing and causing lock recursion on the zone lock. > Lockdep should make all of this a lot easier to find. Is it being used? I do have it in the function which returns the pages to the buddy but I missed it in the function that isolates the pages. I will correct this. -- 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
Re: [virtio-dev] Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting
On 10/1/19 4:25 PM, Alexander Duyck wrote: > On Tue, 2019-10-01 at 15:16 -0400, Nitesh Narayan Lal wrote: >> On 10/1/19 12:21 PM, Alexander Duyck wrote: >>> On Tue, 2019-10-01 at 17:35 +0200, David Hildenbrand wrote: >>>> On 01.10.19 17:29, Alexander Duyck wrote: > > >>>>> As far as possible regressions I have focused on cases where performing >>>>> the hinting would be non-optimal, such as cases where the code isn't >>>>> needed as memory is not over-committed, or the functionality is not in >>>>> use. I have been using the will-it-scale/page_fault1 test running with 16 >>>>> vcpus and have modified it to use Transparent Huge Pages. With this I see >>>>> almost no difference with the patches applied and the feature disabled. >>>>> Likewise I see almost no difference with the feature enabled, but the >>>>> madvise disabled in the hypervisor due to a device being assigned. With >>>>> the feature fully enabled in both guest and hypervisor I see a regression >>>>> between -1.86% and -8.84% versus the baseline. I found that most of the >>>>> overhead was due to the page faulting/zeroing that comes as a result of >>>>> the pages having been evicted from the guest. >>>> I think Michal asked for a performance comparison against Nitesh's >>>> approach, to evaluate if keeping the reported state + tracking inside >>>> the buddy is really worth it. Do you have any such numbers already? (or >>>> did my tired eyes miss them in this cover letter? :/) >>>> >>> I thought what Michal was asking for was what was the benefit of using the >>> boundary pointer. I added a bit up above and to the description for patch >>> 3 as on a 32G VM it adds up to about a 18% difference without factoring in >>> the page faulting and zeroing logic that occurs when we actually do the >>> madvise. >>> >>> Do we have a working patch set for Nitesh's code? The last time I tried >>> running his patch set I ran into issues with kernel panics. If we have a >>> known working/stable patch set I can give it a try. >> Did you try the v12 patch-set [1]? >> I remember that you reported the CPU stall issue, which I fixed in the v12. >> >> [1] https://lkml.org/lkml/2019/8/12/593 >> >>> - Alex >>> > I haven't tested it. I will pull the patches and give it a try. It works > with the same QEMU changes that mine does right? If so we should be able > to get an apples-to-apples comparison. Yes. > > Also, instead of providing lkml.org links to your patches in the future it > might be better to provide a link to the lore.kernel.org version of the > thread. So for example the v12 set would be: > https://lore.kernel.org/lkml/20190812131235.27244-1-nit...@redhat.com/ I see, I will keep that in mind. Thanks for pointing this out. > > The advantage is you can just look up the message ID in your own inbox to > figure out the link, and it provides raw access to the email if needed. > > Thanks. > > - Alex > > > - > To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org > For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org > -- 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 v11 0/6] mm / virtio: Provide support for unused page reporting
On 10/2/19 10:25 AM, Alexander Duyck wrote: > On Wed, Oct 2, 2019 at 3:37 AM Nitesh Narayan Lal wrote: >> >> On 10/1/19 8:55 PM, Alexander Duyck wrote: >>> On Tue, Oct 1, 2019 at 12:16 PM Nitesh Narayan Lal >>> wrote: >>>> On 10/1/19 12:21 PM, Alexander Duyck wrote: >>>>> On Tue, 2019-10-01 at 17:35 +0200, David Hildenbrand wrote: >>>>>> On 01.10.19 17:29, Alexander Duyck wrote: > > >>>>> Do we have a working patch set for Nitesh's code? The last time I tried >>>>> running his patch set I ran into issues with kernel panics. If we have a >>>>> known working/stable patch set I can give it a try. >>>> Did you try the v12 patch-set [1]? >>>> I remember that you reported the CPU stall issue, which I fixed in the v12. >>>> >>>> [1] https://lkml.org/lkml/2019/8/12/593 >>> So I tried testing with the spin_lock calls replaced with spin_lock >>> _irq to resolve the IRQ issue. I also had shuffle enabled in order to >>> increase the number of pages being dirtied. >>> >>> With that setup the bitmap approach is running significantly worse >>> then my approach, even with the boundary removed. Since I had to >>> modify the code to even getting working I am not comfortable posting >>> numbers. >> I didn't face any issue in getting the code work or compile. >> Before my v12 posting, I did try your previously suggested test >> (will-it-scale/page_fault1 for 12 hours on a 60 GB) and didn't see any >> issues. >> I think it would help more if you can share the setup which you are running. > So one issue with the standard page_fault1 is that it is only > operating at the 4K page level. You won't see much impact from you > patches with that as the overhead of splitting a MAX_ORDER - 2 page > down to a 4K page will end up being the biggest thing you are > benchmarking. > > I think I have brought it up before but I am running with the > page_fault1 modified to use THP. Making the change is pretty > straightforward as all you have to do is add an madvise to the test > code. All that is needed is to add "madvise(c, MEMSIZE, > MADV_HUGEPAGE);" between the assert and the for loop in the > page_fault1 code and then rebuild the test. I actually copied > page_fault1.c into a file I named page_fault4.c and added the line. As > a result it seems like the code will build it as an additional test. Thanks for explaining. > > The only other alteration I can think of that might have much impact > would be to enable the page shuffling. The idea is that it will cause > us to use more pages because half of the pages freed are dumped to the > tail of the list so we are constantly churning the memory. > >>> My suggestion would be to look at reworking the patch set and >>> post numbers for my patch set versus the bitmap approach and we can >>> look at them then. >> Agreed. However, in order to fix an issue I have to reproduce it first. > With the tweak I have suggested above it should make it much easier to > reproduce. Basically all you need is to have the allocation competing > against hinting. Currently the hinting isn't doing this because the > allocations are mostly coming out of 4K pages instead of higher order > ones. Understood. > > Alternatively you could just make the suggestion I had proposed about > using spin_lock/unlock_irq in your worker thread and that resolved it > for me. I will first reproduce as you suggested and then make the change. That will help me to understand the issue in a better way. > >>> I would prefer not to spend my time fixing and >>> tuning a patch set that I am still not convinced is viable. >> You don't have to, I can fix the issues in my patch-set. :) > Sounds good. Hopefully the stuff I pointed out above helps you to get > a reproduction and resolve the issues. Indeed, I will try these suggestions and fix this issue. Did you run into any other issues while building or running? > > - Alex -- 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 v11 0/6] mm / virtio: Provide support for unused page reporting
On 10/2/19 3:13 AM, David Hildenbrand wrote: > On 02.10.19 02:55, Alexander Duyck wrote: >> On Tue, Oct 1, 2019 at 12:16 PM Nitesh Narayan Lal wrote: >>> >>> On 10/1/19 12:21 PM, Alexander Duyck wrote: >>>> On Tue, 2019-10-01 at 17:35 +0200, David Hildenbrand wrote: >>>>> On 01.10.19 17:29, 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 advantage of >>>>>> unused page reporting is that we can support a significant amount of >>>>>> memory over-commit with improved performance as we can avoid having to >>>>>> write/read memory from swap as the VM will instead actively participate >>>>>> in freeing unused memory so it doesn't have to be written. >>>>>> >>>>>> 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 non-reported pages off of the free lists of a given zone and >>>>>> placing them into a scatterlist. 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. After this they are placed back on their >>>>>> original free list. If they are not merged in freeing an additional bit >>>>>> is >>>>>> set 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. >>>>>> >>>>>> In order to try and keep the time needed to find a non-reported page to >>>>>> a minimum we maintain a "reported_boundary" pointer. This pointer is used >>>>>> by the get_unreported_pages iterator to determine at what point it should >>>>>> resume searching for non-reported pages. In order to guarantee pages do >>>>>> not get past the scan I have modified add_to_free_list_tail so that it >>>>>> will not insert pages behind the reported_boundary. Doing this allows us >>>>>> to keep the overhead to a minimum as re-walking the list without the >>>>>> boundary will result in as much as 18% additional overhead on a 32G VM. >>>>>> >>>>>> >>>> >>>> >>>>>> As far as possible regressions I have focused on cases where performing >>>>>> the hinting would be non-optimal, such as cases where the code isn't >>>>>> needed as memory is not over-committed, or the functionality is not in >>>>>> use. I have been using the will-it-scale/page_fault1 test running with 16 >>>>>> vcpus and have modified it to use Transparent Huge Pages. With this I see >>>>>> almost no difference with the patches applied and the feature disabled. >>>>>> Likewise I see almost no difference with the feature enabled, but the >>>>>> madvise disabled in the hypervisor due to a device being assigned. With >>>>>> the feature fully enabled in both guest and hypervisor I see a regression >>>>>> between -1.86% and -8.84% versus the baseline. I found that most of the >>>>>> overhead was due to the page faulting/zeroing that comes as a result of >>>>>> the pages having been evicted from the guest. >>>>> I think Michal asked for a performance comparison against Nitesh's >>>>> approach, to evaluate if keeping the reported state + tracking inside >>>>> the buddy is really worth it. Do you have any such numbers already? (or >>>>> did my tired eyes miss them in this cover letter? :/) >>>>> >>>> I though
[virtio-dev] Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting
On 10/1/19 8:55 PM, Alexander Duyck wrote: > On Tue, Oct 1, 2019 at 12:16 PM Nitesh Narayan Lal wrote: >> >> On 10/1/19 12:21 PM, Alexander Duyck wrote: >>> On Tue, 2019-10-01 at 17:35 +0200, David Hildenbrand wrote: >>>> On 01.10.19 17:29, 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 advantage of >>>>> unused page reporting is that we can support a significant amount of >>>>> memory over-commit with improved performance as we can avoid having to >>>>> write/read memory from swap as the VM will instead actively participate >>>>> in freeing unused memory so it doesn't have to be written. >>>>> >>>>> 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 non-reported pages off of the free lists of a given zone and >>>>> placing them into a scatterlist. 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. After this they are placed back on their >>>>> original free list. If they are not merged in freeing an additional bit is >>>>> set 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. >>>>> >>>>> In order to try and keep the time needed to find a non-reported page to >>>>> a minimum we maintain a "reported_boundary" pointer. This pointer is used >>>>> by the get_unreported_pages iterator to determine at what point it should >>>>> resume searching for non-reported pages. In order to guarantee pages do >>>>> not get past the scan I have modified add_to_free_list_tail so that it >>>>> will not insert pages behind the reported_boundary. Doing this allows us >>>>> to keep the overhead to a minimum as re-walking the list without the >>>>> boundary will result in as much as 18% additional overhead on a 32G VM. >>>>> >>>>> >>> >>> >>>>> As far as possible regressions I have focused on cases where performing >>>>> the hinting would be non-optimal, such as cases where the code isn't >>>>> needed as memory is not over-committed, or the functionality is not in >>>>> use. I have been using the will-it-scale/page_fault1 test running with 16 >>>>> vcpus and have modified it to use Transparent Huge Pages. With this I see >>>>> almost no difference with the patches applied and the feature disabled. >>>>> Likewise I see almost no difference with the feature enabled, but the >>>>> madvise disabled in the hypervisor due to a device being assigned. With >>>>> the feature fully enabled in both guest and hypervisor I see a regression >>>>> between -1.86% and -8.84% versus the baseline. I found that most of the >>>>> overhead was due to the page faulting/zeroing that comes as a result of >>>>> the pages having been evicted from the guest. >>>> I think Michal asked for a performance comparison against Nitesh's >>>> approach, to evaluate if keeping the reported state + tracking inside >>>> the buddy is really worth it. Do you have any such numbers already? (or >>>> did my tired eyes miss them in this cover letter? :/) >>>> >>> I thought what Michal was asking for was what was the benefit of using the >>> boundary pointer. I added a bit up above and to the description for patch >>> 3 as on a 32G VM it adds up to about a 18% difference without factoring in >>> the page faulting and zeroing logic that occurs when we actually do the >>> madvise. >>> >>> Do we have a working patch set for
[virtio-dev] Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting
On 10/1/19 2:41 PM, David Hildenbrand wrote: >>> I think Michal asked for a performance comparison against Nitesh's >>> approach, to evaluate if keeping the reported state + tracking inside >>> the buddy is really worth it. Do you have any such numbers already? (or >>> did my tired eyes miss them in this cover letter? :/) >>> >> I thought what Michal was asking for was what was the benefit of using the >> boundary pointer. I added a bit up above and to the description for patch >> 3 as on a 32G VM it adds up to about a 18% difference without factoring in >> the page faulting and zeroing logic that occurs when we actually do the >> madvise. > "I would still be happier if the allocator wouldn't really have to > bother about somebody snooping its internal state to do its own thing. > So make sure to describe why and how much this really matters. > [...] > if you gave some rough numbers to quantify how much overhead for > different solutions we are talking about here. > " > > Could be that I'm misreading Michals comment, but I'd be interested in > the "how much" as well. > >> Do we have a working patch set for Nitesh's code? The last time I tried >> running his patch set I ran into issues with kernel panics. If we have a >> known working/stable patch set I can give it a try. > @Nitesh, is there a working branch? For some unknown reason, I received these set of emails just now :) That's why couldn't respond earlier. > > -- 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 v11 0/6] mm / virtio: Provide support for unused page reporting
On 10/1/19 12:21 PM, Alexander Duyck wrote: > On Tue, 2019-10-01 at 17:35 +0200, David Hildenbrand wrote: >> On 01.10.19 17:29, 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 advantage of >>> unused page reporting is that we can support a significant amount of >>> memory over-commit with improved performance as we can avoid having to >>> write/read memory from swap as the VM will instead actively participate >>> in freeing unused memory so it doesn't have to be written. >>> >>> 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 non-reported pages off of the free lists of a given zone and >>> placing them into a scatterlist. 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. After this they are placed back on their >>> original free list. If they are not merged in freeing an additional bit is >>> set 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. >>> >>> In order to try and keep the time needed to find a non-reported page to >>> a minimum we maintain a "reported_boundary" pointer. This pointer is used >>> by the get_unreported_pages iterator to determine at what point it should >>> resume searching for non-reported pages. In order to guarantee pages do >>> not get past the scan I have modified add_to_free_list_tail so that it >>> will not insert pages behind the reported_boundary. Doing this allows us >>> to keep the overhead to a minimum as re-walking the list without the >>> boundary will result in as much as 18% additional overhead on a 32G VM. >>> >>> > > >>> As far as possible regressions I have focused on cases where performing >>> the hinting would be non-optimal, such as cases where the code isn't >>> needed as memory is not over-committed, or the functionality is not in >>> use. I have been using the will-it-scale/page_fault1 test running with 16 >>> vcpus and have modified it to use Transparent Huge Pages. With this I see >>> almost no difference with the patches applied and the feature disabled. >>> Likewise I see almost no difference with the feature enabled, but the >>> madvise disabled in the hypervisor due to a device being assigned. With >>> the feature fully enabled in both guest and hypervisor I see a regression >>> between -1.86% and -8.84% versus the baseline. I found that most of the >>> overhead was due to the page faulting/zeroing that comes as a result of >>> the pages having been evicted from the guest. >> I think Michal asked for a performance comparison against Nitesh's >> approach, to evaluate if keeping the reported state + tracking inside >> the buddy is really worth it. Do you have any such numbers already? (or >> did my tired eyes miss them in this cover letter? :/) >> > I thought what Michal was asking for was what was the benefit of using the > boundary pointer. I added a bit up above and to the description for patch > 3 as on a 32G VM it adds up to about a 18% difference without factoring in > the page faulting and zeroing logic that occurs when we actually do the > madvise. > > Do we have a working patch set for Nitesh's code? The last time I tried > running his patch set I ran into issues with kernel panics. If we have a > known working/stable patch set I can give it a try. Did you try the v12 patch-set [1]? I remember that you reported the CPU stall issue, which I fixed in the v12. [1] https://lkml.org/lkml/2019/8/12/593 > > - Alex > -- 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 v10 0/6] mm / virtio: Provide support for unused page reporting
On 9/24/19 11:32 AM, David Hildenbrand wrote: > On 24.09.19 16:23, Michal Hocko wrote: >> On Wed 18-09-19 10:52:25, Alexander Duyck wrote: >> [...] >>> In order to try and keep the time needed to find a non-reported page to >>> a minimum we maintain a "reported_boundary" pointer. This pointer is used >>> by the get_unreported_pages iterator to determine at what point it should >>> resume searching for non-reported pages. In order to guarantee pages do >>> not get past the scan I have modified add_to_free_list_tail so that it >>> will not insert pages behind the reported_boundary. >>> >>> If another process needs to perform a massive manipulation of the free >>> list, such as compaction, it can either reset a given individual boundary >>> which will push the boundary back to the list_head, or it can clear the >>> bit indicating the zone is actively processing which will result in the >>> reporting process resetting all of the boundaries for a given zone. >> Is this any different from the previous version? The last review >> feedback (both from me and Mel) was that we are not happy to have an >> externally imposed constrains on how the page allocator is supposed to >> maintain its free lists. >> >> If this is really the only way to go forward then I would like to hear >> very convincing arguments about other approaches not being feasible. > Adding to what Alexander said, I don't consider the other approaches > (especially the bitmap-based approach Nitesh is currently working on) > infeasible. There might be more rough edges (e.g., sparse zones) and > eventually sometimes a little more work to be done, but definitely > feasible. Incorporating stuff into the buddy might make some tasks > (e.g., identify free pages) more efficient. My plan was to get a framework ready which can perform decently and is acceptable upstream (keeping core-mm changes to a minimum) and then keep optimizing it for different use-cases. Indeed, the bitmap-based approach may not be efficient for every available use case. But then I am not sure if we want to target that, considering it may require mm-changes. > I still somewhat like the idea of capturing hints of free pages (in > whatever data structure) and then going over the hints, seeing if the > pages are still free. Then only temporarily isolating the still-free > pages, reporting them, and un-isolating them after they were reported. I > like the idea that the pages are not fake-allocated but only temporarily > blocked. That works nicely e.g., with the movable zone (contain only > movable data). > > But anyhow, after decades of people working on free page > hinting/reporting, I am happy with anything that gets accepted upstream :D +1 > -- 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 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 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 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: [RFC][Patch v12 1/2] mm: page_reporting: core infrastructure
On 8/30/19 11:31 AM, Alexander Duyck wrote:
> On Fri, Aug 30, 2019 at 8:15 AM Nitesh Narayan Lal wrote:
>>
>> On 8/12/19 2:47 PM, Alexander Duyck wrote:
>>> On Mon, Aug 12, 2019 at 6:13 AM Nitesh Narayan Lal
>>> wrote:
>>>> This patch introduces the core infrastructure for free page reporting in
>>>> virtual environments. It enables the kernel to track the free pages which
>>>> can be reported to its hypervisor so that the hypervisor could
>>>> free and reuse that memory as per its requirement.
>>>>
>>>> While the pages are getting processed in the hypervisor (e.g.,
>>>> via MADV_DONTNEED), the guest must not use them, otherwise, data loss
>>>> would be possible. To avoid such a situation, these pages are
>>>> temporarily removed from the buddy. The amount of pages removed
>>>> temporarily from the buddy is governed by the backend(virtio-balloon
>>>> in our case).
>>>>
>>>> To efficiently identify free pages that can to be reported to the
>>>> hypervisor, bitmaps in a coarse granularity are used. Only fairly big
>>>> chunks are reported to the hypervisor - especially, to not break up THP
>>>> in the hypervisor - "MAX_ORDER - 2" on x86, and to save space. The bits
>>>> in the bitmap are an indication whether a page *might* be free, not a
>>>> guarantee. A new hook after buddy merging sets the bits.
>>>>
>>>> Bitmaps are stored per zone, protected by the zone lock. A workqueue
>>>> asynchronously processes the bitmaps, trying to isolate and report pages
>>>> that are still free. The backend (virtio-balloon) is responsible for
>>>> reporting these batched pages to the host synchronously. Once reporting/
>>>> freeing is complete, isolated pages are returned back to the buddy.
>>>>
>>>> Signed-off-by: Nitesh Narayan Lal
>> [...]
>>>> +static void scan_zone_bitmap(struct page_reporting_config *phconf,
>>>> +struct zone *zone)
>>>> +{
>>>> + unsigned long setbit;
>>>> + struct page *page;
>>>> + int count = 0;
>>>> +
>>>> + sg_init_table(phconf->sg, phconf->max_pages);
>>>> +
>>>> + for_each_set_bit(setbit, zone->bitmap, zone->nbits) {
>>>> + /* Process only if the page is still online */
>>>> + page = pfn_to_online_page((setbit <<
>>>> PAGE_REPORTING_MIN_ORDER) +
>>>> + zone->base_pfn);
>>>> + if (!page)
>>>> + continue;
>>>> +
>>> Shouldn't you be clearing the bit and dropping the reference to
>>> free_pages before you move on to the next bit? Otherwise you are going
>>> to be stuck with those aren't you?
>>>
>>>> + spin_lock(>lock);
>>>> +
>>>> + /* Ensure page is still free and can be processed */
>>>> + if (PageBuddy(page) && page_private(page) >=
>>>> + PAGE_REPORTING_MIN_ORDER)
>>>> + count = process_free_page(page, phconf, count);
>>>> +
>>>> + spin_unlock(>lock);
>>> So I kind of wonder just how much overhead you are taking for bouncing
>>> the zone lock once per page here. Especially since it can result in
>>> you not actually making any progress since the page may have already
>>> been reallocated.
>>>
>> I am wondering if there is a way to measure this overhead?
>> After thinking about this, I do understand your point.
>> One possible way which I can think of to address this is by having a
>> page_reporting_dequeue() hook somewhere in the allocation path.
> Really in order to stress this you probably need to have a lot of
> CPUs, a lot of memory, and something that forces a lot of pages to get
> hit such as the memory shuffling feature.
I will think about it, thanks for the suggestion.
>
>> For some reason, I am not seeing this work as I would have expected
>> but I don't have solid reasoning to share yet. It could be simply
>> because I am putting my hook at the wrong place. I will continue
>> investigating this.
>>
>> In any case, I may be over complicating things here, so please let me
>> if there is a better way to do this.
> I have already been demonstrating the "better way"
[virtio-dev] Re: [RFC][Patch v12 1/2] mm: page_reporting: core infrastructure
On 8/12/19 2:47 PM, Alexander Duyck wrote:
> On Mon, Aug 12, 2019 at 6:13 AM Nitesh Narayan Lal wrote:
>> This patch introduces the core infrastructure for free page reporting in
>> virtual environments. It enables the kernel to track the free pages which
>> can be reported to its hypervisor so that the hypervisor could
>> free and reuse that memory as per its requirement.
>>
>> While the pages are getting processed in the hypervisor (e.g.,
>> via MADV_DONTNEED), the guest must not use them, otherwise, data loss
>> would be possible. To avoid such a situation, these pages are
>> temporarily removed from the buddy. The amount of pages removed
>> temporarily from the buddy is governed by the backend(virtio-balloon
>> in our case).
>>
>> To efficiently identify free pages that can to be reported to the
>> hypervisor, bitmaps in a coarse granularity are used. Only fairly big
>> chunks are reported to the hypervisor - especially, to not break up THP
>> in the hypervisor - "MAX_ORDER - 2" on x86, and to save space. The bits
>> in the bitmap are an indication whether a page *might* be free, not a
>> guarantee. A new hook after buddy merging sets the bits.
>>
>> Bitmaps are stored per zone, protected by the zone lock. A workqueue
>> asynchronously processes the bitmaps, trying to isolate and report pages
>> that are still free. The backend (virtio-balloon) is responsible for
>> reporting these batched pages to the host synchronously. Once reporting/
>> freeing is complete, isolated pages are returned back to the buddy.
>>
>> Signed-off-by: Nitesh Narayan Lal
[...]
>> +static void scan_zone_bitmap(struct page_reporting_config *phconf,
>> +struct zone *zone)
>> +{
>> + unsigned long setbit;
>> + struct page *page;
>> + int count = 0;
>> +
>> + sg_init_table(phconf->sg, phconf->max_pages);
>> +
>> + for_each_set_bit(setbit, zone->bitmap, zone->nbits) {
>> + /* Process only if the page is still online */
>> + page = pfn_to_online_page((setbit <<
>> PAGE_REPORTING_MIN_ORDER) +
>> + zone->base_pfn);
>> + if (!page)
>> + continue;
>> +
> Shouldn't you be clearing the bit and dropping the reference to
> free_pages before you move on to the next bit? Otherwise you are going
> to be stuck with those aren't you?
>
>> + spin_lock(>lock);
>> +
>> + /* Ensure page is still free and can be processed */
>> + if (PageBuddy(page) && page_private(page) >=
>> + PAGE_REPORTING_MIN_ORDER)
>> + count = process_free_page(page, phconf, count);
>> +
>> + spin_unlock(>lock);
> So I kind of wonder just how much overhead you are taking for bouncing
> the zone lock once per page here. Especially since it can result in
> you not actually making any progress since the page may have already
> been reallocated.
>
I am wondering if there is a way to measure this overhead?
After thinking about this, I do understand your point.
One possible way which I can think of to address this is by having a
page_reporting_dequeue() hook somewhere in the allocation path.
For some reason, I am not seeing this work as I would have expected
but I don't have solid reasoning to share yet. It could be simply
because I am putting my hook at the wrong place. I will continue
investigating this.
In any case, I may be over complicating things here, so please let me
if there is a better way to do this.
If this overhead is not significant we can probably live with 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
Re: [virtio-dev] [PATCH v6 4/6] mm: Introduce Reported pages
On 8/21/19 10:59 AM, Alexander Duyck wrote:
> From: Alexander Duyck
>
> In order to pave the way for free page reporting in virtualized
> environments we will need a way to get pages out of the free lists and
> identify those pages after they have been returned. To accomplish this,
> this patch adds the concept of a Reported Buddy, which is essentially
> meant to just be the Uptodate flag used in conjunction with the Buddy
> page type.
>
> It adds a set of pointers we shall call "boundary" which represents the
> upper boundary between the unreported and reported pages. The general idea
> is that in order for a page to cross from one side of the boundary to the
> other it will need to go through the reporting process. Ultimately a
> free_list has been fully processed when the boundary has been moved from
> the tail all they way up to occupying the first entry in the list.
>
> Doing this we should be able to make certain that we keep the reported
> pages as one contiguous block in each free list. This will allow us to
> efficiently manipulate the free lists whenever we need to go in and start
> sending reports to the hypervisor that there are new pages that have been
> freed and are no longer in use.
>
> An added advantage to this approach is that we should be reducing the
> overall memory footprint of the guest as it will be more likely to recycle
> warm pages versus trying to allocate the reported pages that were likely
> evicted from the guest memory.
>
> Since we will only be reporting one zone at a time we keep the boundary
> limited to being defined for just the zone we are currently reporting pages
> from. Doing this we can keep the number of additional pointers needed quite
> small. To flag that the boundaries are in place we use a single bit
> in the zone to indicate that reporting and the boundaries are active.
>
> The determination of when to start reporting is based on the tracking of
> the number of free pages in a given area versus the number of reported
> pages in that area. We keep track of the number of reported pages per
> free_area in a separate zone specific area. We do this to avoid modifying
> the free_area structure as this can lead to false sharing for the highest
> order with the zone lock which leads to a noticeable performance
> degradation.
[...]
> +
> +/* request page reporting on this zone */
> +void __page_reporting_request(struct zone *zone)
> +{
> + struct page_reporting_dev_info *phdev;
> +
> + rcu_read_lock();
> +
> + /*
> + * We use RCU to protect the ph_dev_info pointer. In almost all
> + * cases this should be present, however in the unlikely case of
> + * a shutdown this will be NULL and we should exit.
> + */
> + phdev = rcu_dereference(ph_dev_info);
> + if (unlikely(!phdev))
> + return;
> +
Just a minor comment here.
Although this is unlikely to trigger still I think you should release the
rcu_read_lock before returning.
> + /*
> + * We can use separate test and set operations here as there
> + * is nothing else that can set or clear this bit while we are
> + * holding the zone lock. The advantage to doing it this way is
> + * that we don't have to dirty the cacheline unless we are
> + * changing the value.
> + */
> + __set_bit(ZONE_PAGE_REPORTING_REQUESTED, >flags);
> +
> + /*
> + * Delay the start of work to allow a sizable queue to
> + * build. For now we are limiting this to running no more
> + * than 10 times per second.
> + */
> + if (!atomic_fetch_inc(>refcnt))
> + schedule_delayed_work(>work, HZ / 10);
> +
> + rcu_read_unlock();
> +}
> +
[...]
> + }
> +
> + /* enable page reporting notification */
> + static_branch_enable(_reporting_notify_enabled);
> +err_out:
> + mutex_unlock(_reporting_mutex);
> +
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(page_reporting_startup);
>
>
> -
> To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
>
--
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: [RFC][Patch v12 1/2] mm: page_reporting: core infrastructure
On 8/12/19 4:04 PM, Nitesh Narayan Lal wrote: > On 8/12/19 2:47 PM, Alexander Duyck wrote: >> On Mon, Aug 12, 2019 at 6:13 AM Nitesh Narayan Lal wrote: >>> This patch introduces the core infrastructure for free page reporting in >>> virtual environments. It enables the kernel to track the free pages which >>> can be reported to its hypervisor so that the hypervisor could >>> free and reuse that memory as per its requirement. >>> >>> While the pages are getting processed in the hypervisor (e.g., >>> via MADV_DONTNEED), the guest must not use them, otherwise, data loss >>> would be possible. To avoid such a situation, these pages are >>> temporarily removed from the buddy. The amount of pages removed >>> temporarily from the buddy is governed by the backend(virtio-balloon >>> in our case). >>> >>> To efficiently identify free pages that can to be reported to the >>> hypervisor, bitmaps in a coarse granularity are used. Only fairly big >>> chunks are reported to the hypervisor - especially, to not break up THP >>> in the hypervisor - "MAX_ORDER - 2" on x86, and to save space. The bits >>> in the bitmap are an indication whether a page *might* be free, not a >>> guarantee. A new hook after buddy merging sets the bits. >>> >>> Bitmaps are stored per zone, protected by the zone lock. A workqueue >>> asynchronously processes the bitmaps, trying to isolate and report pages >>> that are still free. The backend (virtio-balloon) is responsible for >>> reporting these batched pages to the host synchronously. Once reporting/ >>> freeing is complete, isolated pages are returned back to the buddy. >>> >>> Signed-off-by: Nitesh Narayan Lal >> So if I understand correctly the hotplug support for this is still not >> included correct? > > That is correct, I have it as an ongoing-item in my cover-email. > In case, we decide to go with this approach do you think it is a blocker? I am planning to defer memory hotplug/hotremove support for the future. Due to following reasons: * I would like to first get a basic framework ready and merged (in case we decide to go ahead with this approach) and then build on top of it. * Memory hotplug/hotremove is not a primary use case in our mind right now and hence I am not considering this as a blocker for the first step. Following are the items which I intend to address before my next submission: * Use zone flag and reference counter to track the number of zones requesting page reporting. * Move the bitmap and its respective fields into a structure whose rcu-protected pointer object is maintained on a per-zone basis. * Pick Alexander's patch for page poisoning support and test them with my patch set. (@Alexander: I will keep your signed-off for these patches to indicate you are the original author, please do let me know there is a better way to give credit). * Address other suggestions/comments received on v12. Looking forward to any suggestions/comments. [...] > + > + /* assign the configuration object provided by the backend */ > + rcu_assign_pointer(page_reporting_conf, phconf); > + > +out: > + mutex_unlock(_reporting_mutex); > + return ret; > +} > +EXPORT_SYMBOL_GPL(page_reporting_enable); > -- > 2.21.0 > -- 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: [RFC][Patch v12 1/2] mm: page_reporting: core infrastructure
On 8/15/19 7:00 PM, Alexander Duyck wrote:
> On Thu, Aug 15, 2019 at 12:23 PM Nitesh Narayan Lal wrote:
[...]
>>>>>>> +}
>>>>>>> +
>>>>>>> +/**
>>>>>>> + * __page_reporting_enqueue - tracks the freed page in the respective
>>>>>>> zone's
>>>>>>> + * bitmap and enqueues a new page reporting job to the workqueue if
>>>>>>> possible.
>>>>>>> + */
>>>>>>> +void __page_reporting_enqueue(struct page *page)
>>>>>>> +{
>>>>>>> + struct page_reporting_config *phconf;
>>>>>>> + struct zone *zone;
>>>>>>> +
>>>>>>> + rcu_read_lock();
>>>>>>> + /*
>>>>>>> +* We should not process this page if either page reporting is
>>>>>>> not
>>>>>>> +* yet completely enabled or it has been disabled by the
>>>>>>> backend.
>>>>>>> +*/
>>>>>>> + phconf = rcu_dereference(page_reporting_conf);
>>>>>>> + if (!phconf)
>>>>>>> + return;
>>>>>>> +
>>>>>>> + zone = page_zone(page);
>>>>>>> + bitmap_set_bit(page, zone);
>>>>>>> +
>>>>>>> + /*
>>>>>>> +* We should not enqueue a job if a previously enqueued
>>>>>>> reporting work
>>>>>>> +* is in progress or we don't have enough free pages in the
>>>>>>> zone.
>>>>>>> +*/
>>>>>>> + if (atomic_read(>free_pages) >= phconf->max_pages &&
>>>>>>> + !atomic_cmpxchg(>refcnt, 0, 1))
>>>>>> This doesn't make any sense to me. Why are you only incrementing the
>>>>>> refcount if it is zero? Combining this with the assignment above, this
>>>>>> isn't really a refcnt. It is just an oversized bitflag.
>>>>> The intent for having an extra variable was to ensure that at a time only
>>>>> one
>>>>> reporting job is enqueued. I do agree that for that purpose I really
>>>>> don't need
>>>>> a reference counter and I should have used something like bool
>>>>> 'page_hinting_active'. But with bool, I think there could be a possible
>>>>> chance
>>>>> of race. Maybe I should rename this variable and keep it as atomic.
>>>>> Any thoughts?
>>>> You could just use a bitflag to achieve what you are doing here. That
>>>> is the primary use case for many of the test_and_set_bit type
>>>> operations. However one issue with doing it as a bitflag is that you
>>>> have no way of telling that you took care of all requesters.
>>> I think you are right, I might end up missing on certain reporting
>>> opportunities in some special cases. Specifically when the pages which are
>>> part of this new reporting request belongs to a section of the bitmap which
>>> has already been scanned. Although, I have failed to reproduce this kind of
>>> situation in an actual setup.
>>>
>>>> That is
>>>> where having an actual reference count comes in handy as you know
>>>> exactly how many zones are requesting to be reported on.
>>> True.
>>>
>>>>>> Also I am pretty sure this results in the opportunity to miss pages
>>>>>> because there is nothing to prevent you from possibly missing a ton of
>>>>>> pages you could hint on if a large number of pages are pushed out all
>>>>>> at once and then the system goes idle in terms of memory allocation
>>>>>> and freeing.
>>>>> I was looking at how you are enqueuing/processing reporting jobs for each
>>>>> zone.
>>>>> I am wondering if I should also consider something on similar lines as
>>>>> having
>>>>> that I might be able to address the concern which you have raised above.
>>>>> But it
>>>>> would also mean that I have to add an additional flag in the zone_flags.
>>>>> :)
>>>> You could do it either in the zone or outside the zone as yet another
>>>> bitmap. I decided to put the flags inside the zone because there was a
>>>> numb
[virtio-dev] Re: [RFC][Patch v12 1/2] mm: page_reporting: core infrastructure
On 8/15/19 9:15 AM, Nitesh Narayan Lal wrote:
> On 8/14/19 12:11 PM, Alexander Duyck wrote:
>> On Wed, Aug 14, 2019 at 8:49 AM Nitesh Narayan Lal wrote:
>>> On 8/12/19 2:47 PM, Alexander Duyck wrote:
>>>> On Mon, Aug 12, 2019 at 6:13 AM Nitesh Narayan Lal
>>>> wrote:
>>>>> This patch introduces the core infrastructure for free page reporting in
>>>>> virtual environments. It enables the kernel to track the free pages which
>>>>> can be reported to its hypervisor so that the hypervisor could
>>>>> free and reuse that memory as per its requirement.
>>>>>
>>>>> While the pages are getting processed in the hypervisor (e.g.,
>>>>> via MADV_DONTNEED), the guest must not use them, otherwise, data loss
>>>>> would be possible. To avoid such a situation, these pages are
>>>>> temporarily removed from the buddy. The amount of pages removed
>>>>> temporarily from the buddy is governed by the backend(virtio-balloon
>>>>> in our case).
>>>>>
>>>>> To efficiently identify free pages that can to be reported to the
>>>>> hypervisor, bitmaps in a coarse granularity are used. Only fairly big
>>>>> chunks are reported to the hypervisor - especially, to not break up THP
>>>>> in the hypervisor - "MAX_ORDER - 2" on x86, and to save space. The bits
>>>>> in the bitmap are an indication whether a page *might* be free, not a
>>>>> guarantee. A new hook after buddy merging sets the bits.
>>>>>
>>>>> Bitmaps are stored per zone, protected by the zone lock. A workqueue
>>>>> asynchronously processes the bitmaps, trying to isolate and report pages
>>>>> that are still free. The backend (virtio-balloon) is responsible for
>>>>> reporting these batched pages to the host synchronously. Once reporting/
>>>>> freeing is complete, isolated pages are returned back to the buddy.
>>>>>
>>>>> Signed-off-by: Nitesh Narayan Lal
>>> [...]
>>>>> +}
>>>>> +
>>>>> +/**
>>>>> + * __page_reporting_enqueue - tracks the freed page in the respective
>>>>> zone's
>>>>> + * bitmap and enqueues a new page reporting job to the workqueue if
>>>>> possible.
>>>>> + */
>>>>> +void __page_reporting_enqueue(struct page *page)
>>>>> +{
>>>>> + struct page_reporting_config *phconf;
>>>>> + struct zone *zone;
>>>>> +
>>>>> + rcu_read_lock();
>>>>> + /*
>>>>> +* We should not process this page if either page reporting is not
>>>>> +* yet completely enabled or it has been disabled by the backend.
>>>>> +*/
>>>>> + phconf = rcu_dereference(page_reporting_conf);
>>>>> + if (!phconf)
>>>>> + return;
>>>>> +
>>>>> + zone = page_zone(page);
>>>>> + bitmap_set_bit(page, zone);
>>>>> +
>>>>> + /*
>>>>> +* We should not enqueue a job if a previously enqueued reporting
>>>>> work
>>>>> +* is in progress or we don't have enough free pages in the zone.
>>>>> +*/
>>>>> + if (atomic_read(>free_pages) >= phconf->max_pages &&
>>>>> + !atomic_cmpxchg(>refcnt, 0, 1))
>>>> This doesn't make any sense to me. Why are you only incrementing the
>>>> refcount if it is zero? Combining this with the assignment above, this
>>>> isn't really a refcnt. It is just an oversized bitflag.
>>> The intent for having an extra variable was to ensure that at a time only
>>> one
>>> reporting job is enqueued. I do agree that for that purpose I really don't
>>> need
>>> a reference counter and I should have used something like bool
>>> 'page_hinting_active'. But with bool, I think there could be a possible
>>> chance
>>> of race. Maybe I should rename this variable and keep it as atomic.
>>> Any thoughts?
>> You could just use a bitflag to achieve what you are doing here. That
>> is the primary use case for many of the test_and_set_bit type
>> operations. However one issue with doing it as a bitflag is that you
>> have no way of telling that you took care of all requesters.
> I think yo
[virtio-dev] Re: [RFC][Patch v12 1/2] mm: page_reporting: core infrastructure
On 8/12/19 2:47 PM, Alexander Duyck wrote:
> On Mon, Aug 12, 2019 at 6:13 AM Nitesh Narayan Lal wrote:
>> This patch introduces the core infrastructure for free page reporting in
>> virtual environments. It enables the kernel to track the free pages which
>> can be reported to its hypervisor so that the hypervisor could
>> free and reuse that memory as per its requirement.
>>
>> While the pages are getting processed in the hypervisor (e.g.,
>> via MADV_DONTNEED), the guest must not use them, otherwise, data loss
>> would be possible. To avoid such a situation, these pages are
>> temporarily removed from the buddy. The amount of pages removed
>> temporarily from the buddy is governed by the backend(virtio-balloon
>> in our case).
>>
>> To efficiently identify free pages that can to be reported to the
>> hypervisor, bitmaps in a coarse granularity are used. Only fairly big
>> chunks are reported to the hypervisor - especially, to not break up THP
>> in the hypervisor - "MAX_ORDER - 2" on x86, and to save space. The bits
>> in the bitmap are an indication whether a page *might* be free, not a
>> guarantee. A new hook after buddy merging sets the bits.
>>
>> Bitmaps are stored per zone, protected by the zone lock. A workqueue
>> asynchronously processes the bitmaps, trying to isolate and report pages
>> that are still free. The backend (virtio-balloon) is responsible for
>> reporting these batched pages to the host synchronously. Once reporting/
>> freeing is complete, isolated pages are returned back to the buddy.
>>
>> Signed-off-by: Nitesh Narayan Lal
>
[...]
>> +}
>> +
>> +/**
>> + * __page_reporting_enqueue - tracks the freed page in the respective zone's
>> + * bitmap and enqueues a new page reporting job to the workqueue if
>> possible.
>> + */
>> +void __page_reporting_enqueue(struct page *page)
>> +{
>> + struct page_reporting_config *phconf;
>> + struct zone *zone;
>> +
>> + rcu_read_lock();
>> + /*
>> +* We should not process this page if either page reporting is not
>> +* yet completely enabled or it has been disabled by the backend.
>> +*/
>> + phconf = rcu_dereference(page_reporting_conf);
>> + if (!phconf)
>> + return;
>> +
>> + zone = page_zone(page);
>> + bitmap_set_bit(page, zone);
>> +
>> + /*
>> +* We should not enqueue a job if a previously enqueued reporting
>> work
>> +* is in progress or we don't have enough free pages in the zone.
>> +*/
>> + if (atomic_read(>free_pages) >= phconf->max_pages &&
>> + !atomic_cmpxchg(>refcnt, 0, 1))
> This doesn't make any sense to me. Why are you only incrementing the
> refcount if it is zero? Combining this with the assignment above, this
> isn't really a refcnt. It is just an oversized bitflag.
The intent for having an extra variable was to ensure that at a time only one
reporting job is enqueued. I do agree that for that purpose I really don't need
a reference counter and I should have used something like bool
'page_hinting_active'. But with bool, I think there could be a possible chance
of race. Maybe I should rename this variable and keep it as atomic.
Any thoughts?
>
> Also I am pretty sure this results in the opportunity to miss pages
> because there is nothing to prevent you from possibly missing a ton of
> pages you could hint on if a large number of pages are pushed out all
> at once and then the system goes idle in terms of memory allocation
> and freeing.
I was looking at how you are enqueuing/processing reporting jobs for each zone.
I am wondering if I should also consider something on similar lines as having
that I might be able to address the concern which you have raised above. But it
would also mean that I have to add an additional flag in the zone_flags. :)
>
[...]
>
>> +EXPORT_SYMBOL_GPL(page_reporting_enable);
>> --
>> 2.21.0
>>
--
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: [RFC][Patch v12 2/2] virtio-balloon: interface to support free page reporting
On 8/14/19 9:42 AM, Cornelia Huck wrote:
> On Wed, 14 Aug 2019 07:47:40 -0400
> Nitesh Narayan Lal wrote:
>
>> On 8/14/19 6:29 AM, Cornelia Huck wrote:
>>> On Mon, 12 Aug 2019 09:12:35 -0400
>>> Nitesh Narayan Lal wrote:
>>>
>>>> Enables the kernel to negotiate VIRTIO_BALLOON_F_REPORTING feature with
>>>> the host. If it is available and page_reporting_flag is set to true,
>>>> page_reporting is enabled and its callback is configured along with
>>>> the max_pages count which indicates the maximum number of pages that
>>>> can be isolated and reported at a time. Currently, only free pages of
>>>> order >= (MAX_ORDER - 2) are reported. To prevent any false OOM
>>>> max_pages count is set to 16.
>>>>
>>>> By default page_reporting feature is enabled and gets loaded as soon
>>>> as the virtio-balloon driver is loaded. However, it could be disabled
>>>> by writing the page_reporting_flag which is a virtio-balloon parameter.
>>>>
>>>> Signed-off-by: Nitesh Narayan Lal
>>>> ---
>>>> drivers/virtio/Kconfig | 1 +
>>>> drivers/virtio/virtio_balloon.c | 64 -
>>>> include/uapi/linux/virtio_balloon.h | 1 +
>>>> 3 files changed, 65 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/virtio/virtio_balloon.c
>>>> b/drivers/virtio/virtio_balloon.c
>>>> index 226fbb995fb0..defec00d4ee2 100644
>>>> --- a/drivers/virtio/virtio_balloon.c
>>>> +++ b/drivers/virtio/virtio_balloon.c
>>> (...)
>>>
>>>> +static void virtballoon_page_reporting_setup(struct virtio_balloon *vb)
>>>> +{
>>>> + struct device *dev = >vdev->dev;
>>>> + int err;
>>>> +
>>>> + vb->page_reporting_conf.report = virtballoon_report_pages;
>>>> + vb->page_reporting_conf.max_pages = PAGE_REPORTING_MAX_PAGES;
>>>> + err = page_reporting_enable(>page_reporting_conf);
>>>> + if (err < 0) {
>>>> + dev_err(dev, "Failed to enable reporting, err = %d\n", err);
>>>> + page_reporting_flag = false;
>>> Should we clear the feature bit in this case as well?
>> I think yes.
> Eww, I didn't recall that we don't call the ->probe callback until
> after feature negotiation has finished, so scratch that particular idea.
>
> For what reasons may page_reporting_enable() fail?
If the guest is low in memory and some allocation required for page reporting
setup fails.
> Does it make sense
> to fail probing the device in that case? And does it make sense to
> re-try later (i.e. leave page_reporting_flag set)?
Re-trying to setup page reporting will mean that virtballoon_probe has to be
called again.
For which the driver has to be re-loaded, isn't?
>
>> If I am not wrong then in a case where page reporting setup fails for some
>> reason and at a later point the user wants to re-enable it then for that
>> balloon
>> driver has to be reloaded.
>> Which would mean re-negotiation of the feature bit.
> Re-negotiation actually already happens if a driver is unbound and
> rebound.
>
>>>
>>>> + vb->page_reporting_conf.report = NULL;
>>>> + vb->page_reporting_conf.max_pages = 0;
>>>> + return;
>>>> + }
>>>> +}
>>>> +
>>>> static void set_page_pfns(struct virtio_balloon *vb,
>>>> __virtio32 pfns[], struct page *page)
>>>> {
>>>> @@ -476,6 +524,7 @@ static int init_vqs(struct virtio_balloon *vb)
>>>>names[VIRTIO_BALLOON_VQ_DEFLATE] = "deflate";
>>>>names[VIRTIO_BALLOON_VQ_STATS] = NULL;
>>>>names[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
>>>> + names[VIRTIO_BALLOON_VQ_REPORTING] = NULL;
>>>>
>>>>if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
>>>>names[VIRTIO_BALLOON_VQ_STATS] = "stats";
>>>> @@ -487,11 +536,18 @@ static int init_vqs(struct virtio_balloon *vb)
>>>>callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
>>>>}
>>>>
>>>> + if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING)) {
>>>> + names[VIRTIO_BALLOON_VQ_REPORTING] = "reporting_vq";
>>>> + callbacks[VIRTIO_BALLOON_VQ_REPORTING] = balloon_ack;
>>> Do we
Re: [virtio-dev] Re: [RFC][Patch v12 1/2] mm: page_reporting: core infrastructure
On 8/14/19 3:07 AM, David Hildenbrand wrote:
> On 14.08.19 01:14, Alexander Duyck wrote:
>> On Tue, Aug 13, 2019 at 3:34 AM David Hildenbrand wrote:
>>> +static int process_free_page(struct page *page,
>>> +struct page_reporting_config *phconf, int
>>> count)
>>> +{
>>> + int mt, order, ret = 0;
>>> +
>>> + mt = get_pageblock_migratetype(page);
>>> + order = page_private(page);
>>> + ret = __isolate_free_page(page, order);
>>> +
> I just started looking into the wonderful world of
> isolation/compaction/migration.
>
> I don't think saving/restoring the migratetype is correct here. AFAIK,
> MOVABLE/UNMOVABLE/RECLAIMABLE is just a hint, doesn't mean that e.g.,
> movable pages and up in UNMOVABLE or ordinary kernel allocations on
> MOVABLE. So that shouldn't be an issue - I guess.
>
> 1. You should never allocate something that is no
> MOVABLE/UNMOVABLE/RECLAIMABLE. Especially not, if you have ISOLATE or
> CMA here. There should at least be a !is_migrate_isolate_page() check
> somewhere
>
> 2. set_migratetype_isolate() takes the zone lock, so to avoid racing
> with isolation code, you have to hold the zone lock. Your code seems to
> do that, so at least you cannot race against isolation.
>
> 3. You could end up temporarily allocating something in the
> ZONE_MOVABLE. The pages you allocate are, however, not movable. There
> would have to be a way to make alloc_contig_range()/offlining code
> properly wait until the pages have been processed. Not sure about the
> real implications, though - too many details in the code (I wonder if
> Alex' series has a way of dealing with that)
>
> When you restore the migratetype, you could suddenly overwrite e.g.,
> ISOLATE, which feels wrong.
I was triggering an occasional CPU stall bug earlier, with saving and
restoring
the migratetype I was able to fix it.
But I will further look into this to figure out if it is really required.
>>> You should especially look into handling isolated/cma pages. Maybe that
>>> was the original issue. Alex seems to have added that in his latest
>>> series (skipping isolated/cma pageblocks completely) as well.
>> So as far as skipping isolated pageblocks, I get the reason for
>> skipping isolated, but why would we need to skip CMA? I had made the
>> change I did based on comments you had made earlier. But while working
>> on some of the changes to address isolation better and looking over
>> several spots in the code it seems like CMA is already being used as
>> an allocation fallback for MIGRATE_MOVABLE. If that is the case
>> wouldn't it make sense to allow pulling pages and reporting them while
>> they are in the free_list?
> I was assuming that CMA is also to be skipped because "static int
> fallbacks[MIGRATE_TYPES][4]" in mm/page_alloc.c doesn't handle CMA at
> all, meaning we should never fallback to CMA or from CMA to another type
> - at least when stealing pages from another migratetype. So it smells
> like MIGRATE_CMA is static -> the area is marked once and will never be
> converted to something else (except MIGRATE_ISOLATE temporarily).
>
> I assume you are talking about gfp_to_alloc_flags()/prepare_alloc_pages():
I am also trying to look into this to get more understanding of it.
Another thing which I am looking into right now is the difference between
get/set_pcppage_migratetype() and ge/set_pageblock_migratetype().
To an extent, I do understand what is the benefit of using
get/set_pcppage_migratetype() by reading the comments. However, I am not sure
how it gets along with MIGRATE_CMA.
Hopefully, I will have an understanding of it soon.
> #ifdef CONFIG_CMA
> if (gfpflags_to_migratetype(gfp_mask) == MIGRATE_MOVABLE)
> alloc_flags |= ALLOC_CMA;
> #endif
>
> Yeah, this looks like MOVABLE allocations can fallback to CMA
> pageblocks. And from what I read, "CMA may use its own migratetype
> (MIGRATE_CMA) which behaves similarly to ZONE_MOVABLE but can be put in
> arbitrary places."
>
> So I think you are right, it could be that it is safe to temporarily
> pull out CMA pages (in contrast to isolated pages) - assuming it is fine
> to have temporary unmovable allocations on them (different discussion).
>
> (I am learning about the details as we discuss :) )
>
> The important part would then be to never allocate from the isolated
> pageblocks and to never overwrite MIGRATE_ISOLATE.
Agreed. I think I should just avoid isolating pages with migratetype
MIGRATE_ISOLATE.
Adding a check with is_migrate_isolate_page() before isolating the page should
do 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: [RFC][Patch v12 2/2] virtio-balloon: interface to support free page reporting
On 8/14/19 6:29 AM, Cornelia Huck wrote:
> On Mon, 12 Aug 2019 09:12:35 -0400
> Nitesh Narayan Lal wrote:
>
>> Enables the kernel to negotiate VIRTIO_BALLOON_F_REPORTING feature with
>> the host. If it is available and page_reporting_flag is set to true,
>> page_reporting is enabled and its callback is configured along with
>> the max_pages count which indicates the maximum number of pages that
>> can be isolated and reported at a time. Currently, only free pages of
>> order >= (MAX_ORDER - 2) are reported. To prevent any false OOM
>> max_pages count is set to 16.
>>
>> By default page_reporting feature is enabled and gets loaded as soon
>> as the virtio-balloon driver is loaded. However, it could be disabled
>> by writing the page_reporting_flag which is a virtio-balloon parameter.
>>
>> Signed-off-by: Nitesh Narayan Lal
>> ---
>> drivers/virtio/Kconfig | 1 +
>> drivers/virtio/virtio_balloon.c | 64 -
>> include/uapi/linux/virtio_balloon.h | 1 +
>> 3 files changed, 65 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/virtio/virtio_balloon.c
>> b/drivers/virtio/virtio_balloon.c
>> index 226fbb995fb0..defec00d4ee2 100644
>> --- a/drivers/virtio/virtio_balloon.c
>> +++ b/drivers/virtio/virtio_balloon.c
> (...)
>
>> +static void virtballoon_page_reporting_setup(struct virtio_balloon *vb)
>> +{
>> +struct device *dev = >vdev->dev;
>> +int err;
>> +
>> +vb->page_reporting_conf.report = virtballoon_report_pages;
>> +vb->page_reporting_conf.max_pages = PAGE_REPORTING_MAX_PAGES;
>> +err = page_reporting_enable(>page_reporting_conf);
>> +if (err < 0) {
>> +dev_err(dev, "Failed to enable reporting, err = %d\n", err);
>> +page_reporting_flag = false;
> Should we clear the feature bit in this case as well?
I think yes.
If I am not wrong then in a case where page reporting setup fails for some
reason and at a later point the user wants to re-enable it then for that balloon
driver has to be reloaded.
Which would mean re-negotiation of the feature bit.
>
>> +vb->page_reporting_conf.report = NULL;
>> +vb->page_reporting_conf.max_pages = 0;
>> +return;
>> +}
>> +}
>> +
>> static void set_page_pfns(struct virtio_balloon *vb,
>>__virtio32 pfns[], struct page *page)
>> {
>> @@ -476,6 +524,7 @@ static int init_vqs(struct virtio_balloon *vb)
>> names[VIRTIO_BALLOON_VQ_DEFLATE] = "deflate";
>> names[VIRTIO_BALLOON_VQ_STATS] = NULL;
>> names[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
>> +names[VIRTIO_BALLOON_VQ_REPORTING] = NULL;
>>
>> if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
>> names[VIRTIO_BALLOON_VQ_STATS] = "stats";
>> @@ -487,11 +536,18 @@ static int init_vqs(struct virtio_balloon *vb)
>> callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
>> }
>>
>> +if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING)) {
>> +names[VIRTIO_BALLOON_VQ_REPORTING] = "reporting_vq";
>> +callbacks[VIRTIO_BALLOON_VQ_REPORTING] = balloon_ack;
> Do we even want to try to set up the reporting queue if reporting has
> been disabled via module parameter? Might make more sense to not even
> negotiate the feature bit in that case.
True.
I think this should be replaced with something like (page_reporting_flag &&
virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING)).
>
>> +}
>> err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
>> vqs, callbacks, names, NULL, NULL);
>> if (err)
>> return err;
>>
>> +if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING))
>> +vb->reporting_vq = vqs[VIRTIO_BALLOON_VQ_REPORTING];
>> +
>> vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE];
>> vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE];
>> if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
>> @@ -924,6 +980,9 @@ static int virtballoon_probe(struct virtio_device *vdev)
>> if (err)
>> goto out_del_balloon_wq;
>> }
>> +if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING) &&
>> +page_reporting_flag)
>> +virtballoon_page_reporting_setup(vb);
> In that case, you'd only need to check
[virtio-dev] Re: [RFC][Patch v12 1/2] mm: page_reporting: core infrastructure
On 8/12/19 4:05 PM, David Hildenbrand wrote:
>>> ---
>>> include/linux/mmzone.h | 11 ++
>>> include/linux/page_reporting.h | 63 +++
>>> mm/Kconfig | 6 +
>>> mm/Makefile| 1 +
>>> mm/page_alloc.c| 42 -
>>> mm/page_reporting.c| 332 +
>>> 6 files changed, 448 insertions(+), 7 deletions(-)
>>> create mode 100644 include/linux/page_reporting.h
>>> create mode 100644 mm/page_reporting.c
>>>
>>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>>> index d77d717c620c..ba5f5b508f25 100644
>>> --- a/include/linux/mmzone.h
>>> +++ b/include/linux/mmzone.h
>>> @@ -559,6 +559,17 @@ struct zone {
>>> /* Zone statistics */
>>> atomic_long_t vm_stat[NR_VM_ZONE_STAT_ITEMS];
>>> atomic_long_t vm_numa_stat[NR_VM_NUMA_STAT_ITEMS];
>>> +#ifdef CONFIG_PAGE_REPORTING
>>> + /* Pointer to the bitmap in PAGE_REPORTING_MIN_ORDER granularity */
>>> + unsigned long *bitmap;
>>> + /* Preserve start and end PFN in case they change due to hotplug */
>>> + unsigned long base_pfn;
>>> + unsigned long end_pfn;
>>> + /* Free pages of granularity PAGE_REPORTING_MIN_ORDER */
>>> + atomic_t free_pages;
>>> + /* Number of bits required in the bitmap */
>>> + unsigned long nbits;
>>> +#endif
>>> } cacheline_internodealigned_in_smp;
>> Okay, so the original thing this patch set had going for it was that
>> it was non-invasive. However, now you are adding a bunch of stuff to
>> the zone. That kind of loses the non-invasive argument for this patch
>> set compared to mine.
>>
> Adding something to "struct zone" is certainly less invasive than core
> buddy modifications, just saying (I agree that this is suboptimal. I
> would have guessed that all that's needed is a pointer to some private
> structure here).
I think having just a pointer to a private structure makes sense here.
If I am not wrong then I can probably make an allocation for it for each
populated zone at the time I enable page reporting.
> However, the migratetype thingy below looks fishy to me.
>
>> If we are going to continue further with this patch set then it might
>> be worth looking into dynamically allocating the space you need for
>> this block. At a minimum you could probably look at making the bitmap
>> an RCU based setup so you could define the base and end along with the
>> bitmap. It would probably help to resolve the hotplug issues you still
>> need to address.
> Yeah, I guess that makes sense.
>
> [...]
>>> +
>>> +static int process_free_page(struct page *page,
>>> +struct page_reporting_config *phconf, int
>>> count)
>>> +{
>>> + int mt, order, ret = 0;
>>> +
>>> + mt = get_pageblock_migratetype(page);
>>> + order = page_private(page);
>>> + ret = __isolate_free_page(page, order);
>>> +
> I just started looking into the wonderful world of
> isolation/compaction/migration.
>
> I don't think saving/restoring the migratetype is correct here. AFAIK,
> MOVABLE/UNMOVABLE/RECLAIMABLE is just a hint, doesn't mean that e.g.,
> movable pages and up in UNMOVABLE or ordinary kernel allocations on
> MOVABLE. So that shouldn't be an issue - I guess.
>
> 1. You should never allocate something that is no
> MOVABLE/UNMOVABLE/RECLAIMABLE. Especially not, if you have ISOLATE or
> CMA here. There should at least be a !is_migrate_isolate_page() check
> somewhere
>
> 2. set_migratetype_isolate() takes the zone lock, so to avoid racing
> with isolation code, you have to hold the zone lock. Your code seems to
> do that, so at least you cannot race against isolation.
>
> 3. You could end up temporarily allocating something in the
> ZONE_MOVABLE. The pages you allocate are, however, not movable. There
> would have to be a way to make alloc_contig_range()/offlining code
> properly wait until the pages have been processed. Not sure about the
> real implications, though - too many details in the code (I wonder if
> Alex' series has a way of dealing with that)
>
> When you restore the migratetype, you could suddenly overwrite e.g.,
> ISOLATE, which feels wrong.
I was triggering an occasional CPU stall bug earlier, with saving and restoring
the migratetype I was able to fix it.
But I will further look into this to figure out if it is really required.
> [...]
>> So as per your comments in the cover page, the two functions above
>> should also probably be plugged into the zone resizing logic somewhere
>> so if a zone is resized the bitmap is adjusted.
>>
>>> +/**
>>> + * zone_reporting_init - For each zone initializes the page reporting
>>> fields
>>> + * and allocates the respective bitmap.
>>> + *
>>> + * This function returns 0 on successful initialization, -ENOMEM otherwise.
>>> + */
>>> +static int zone_reporting_init(void)
>>> +{
>>> + struct zone *zone;
>>> + int ret;
>>> +
>>> +
[virtio-dev] Re: [RFC][Patch v12 1/2] mm: page_reporting: core infrastructure
On 8/12/19 2:47 PM, Alexander Duyck wrote:
> On Mon, Aug 12, 2019 at 6:13 AM Nitesh Narayan Lal wrote:
>> This patch introduces the core infrastructure for free page reporting in
>> virtual environments. It enables the kernel to track the free pages which
>> can be reported to its hypervisor so that the hypervisor could
>> free and reuse that memory as per its requirement.
>>
>> While the pages are getting processed in the hypervisor (e.g.,
>> via MADV_DONTNEED), the guest must not use them, otherwise, data loss
>> would be possible. To avoid such a situation, these pages are
>> temporarily removed from the buddy. The amount of pages removed
>> temporarily from the buddy is governed by the backend(virtio-balloon
>> in our case).
>>
>> To efficiently identify free pages that can to be reported to the
>> hypervisor, bitmaps in a coarse granularity are used. Only fairly big
>> chunks are reported to the hypervisor - especially, to not break up THP
>> in the hypervisor - "MAX_ORDER - 2" on x86, and to save space. The bits
>> in the bitmap are an indication whether a page *might* be free, not a
>> guarantee. A new hook after buddy merging sets the bits.
>>
>> Bitmaps are stored per zone, protected by the zone lock. A workqueue
>> asynchronously processes the bitmaps, trying to isolate and report pages
>> that are still free. The backend (virtio-balloon) is responsible for
>> reporting these batched pages to the host synchronously. Once reporting/
>> freeing is complete, isolated pages are returned back to the buddy.
>>
>> Signed-off-by: Nitesh Narayan Lal
> So if I understand correctly the hotplug support for this is still not
> included correct?
That is correct, I have it as an ongoing-item in my cover-email.
In case, we decide to go with this approach do you think it is a blocker?
> I assume that is the case since I don't see any
> logic for zone resizing.
>
> Also I don't see how this dealt with the sparse issue that was pointed
> out earlier. Specifically how would you deal with a zone that has a
> wide range between the base and the end and a huge gap somewhere
> in-between?
It doesn't. However, considering we are tracking page on order of (MAX_ORDER -
2) I don't think the loss will be significant.
In any case, this is certainly a drawback of this approach and I should add this
in my cover.
The one thing which I did change in this version is that now I started
maintaining bitmap for each zone.
>
>> ---
>> include/linux/mmzone.h | 11 ++
>> include/linux/page_reporting.h | 63 +++
>> mm/Kconfig | 6 +
>> mm/Makefile| 1 +
>> mm/page_alloc.c| 42 -
>> mm/page_reporting.c| 332 +
>> 6 files changed, 448 insertions(+), 7 deletions(-)
>> create mode 100644 include/linux/page_reporting.h
>> create mode 100644 mm/page_reporting.c
>>
>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>> index d77d717c620c..ba5f5b508f25 100644
>> --- a/include/linux/mmzone.h
>> +++ b/include/linux/mmzone.h
>> @@ -559,6 +559,17 @@ struct zone {
>> /* Zone statistics */
>> atomic_long_t vm_stat[NR_VM_ZONE_STAT_ITEMS];
>> atomic_long_t vm_numa_stat[NR_VM_NUMA_STAT_ITEMS];
>> +#ifdef CONFIG_PAGE_REPORTING
>> + /* Pointer to the bitmap in PAGE_REPORTING_MIN_ORDER granularity */
>> + unsigned long *bitmap;
>> + /* Preserve start and end PFN in case they change due to hotplug */
>> + unsigned long base_pfn;
>> + unsigned long end_pfn;
>> + /* Free pages of granularity PAGE_REPORTING_MIN_ORDER */
>> + atomic_t free_pages;
>> + /* Number of bits required in the bitmap */
>> + unsigned long nbits;
>> +#endif
>> } cacheline_internodealigned_in_smp;
> Okay, so the original thing this patch set had going for it was that
> it was non-invasive. However, now you are adding a bunch of stuff to
> the zone. That kind of loses the non-invasive argument for this patch
> set compared to mine.
I think it is fair to add that it not as invasive as yours. :) (But that has its
own pros and cons)
In any case, I do understand your point.
>
>
> If we are going to continue further with this patch set then it might
> be worth looking into dynamically allocating the space you need for
> this block.
Not sure if I understood this part. Dynamic allocation for the structure which
you are suggesting below?
> At a minimum you could probably look at making the bitmap
> an RCU based setup so you could def
[virtio-dev] Re: [QEMU Patch 2/2] virtio-balloon: support for handling page reporting
On 8/12/19 11:18 AM, Alexander Duyck wrote:
> On Mon, Aug 12, 2019 at 6:14 AM Nitesh Narayan Lal wrote:
>> Page reporting is a feature which enables the virtual machine to report
>> chunk of free pages to the hypervisor.
>> This patch enables QEMU to process these reports from the VM and discard the
>> unused memory range.
>>
>> Signed-off-by: Nitesh Narayan Lal
>> ---
>> hw/virtio/virtio-balloon.c | 41 ++
>> include/hw/virtio/virtio-balloon.h | 2 +-
>> 2 files changed, 42 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
>> index 25de154307..1132e47ee0 100644
>> --- a/hw/virtio/virtio-balloon.c
>> +++ b/hw/virtio/virtio-balloon.c
>> @@ -320,6 +320,39 @@ static void balloon_stats_set_poll_interval(Object
>> *obj, Visitor *v,
>> balloon_stats_change_timer(s, 0);
>> }
>>
>> +static void virtio_balloon_handle_reporting(VirtIODevice *vdev, VirtQueue
>> *vq)
>> +{
>> +VirtQueueElement *elem;
>> +
>> +while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement {
>> +unsigned int i;
>> +
>> +for (i = 0; i < elem->in_num; i++) {
>> +void *gaddr = elem->in_sg[i].iov_base;
>> +size_t size = elem->in_sg[i].iov_len;
>> +ram_addr_t ram_offset;
>> +size_t rb_page_size;
>> + RAMBlock *rb;
>> +
>> +if (qemu_balloon_is_inhibited())
>> +continue;
>> +
>> +rb = qemu_ram_block_from_host(gaddr, false, _offset);
>> +rb_page_size = qemu_ram_pagesize(rb);
>> +
>> +/* For now we will simply ignore unaligned memory regions */
>> +if ((ram_offset | size) & (rb_page_size - 1))
>> +continue;
>> +
>> +ram_block_discard_range(rb, ram_offset, size);
>> +}
>> +
>> +virtqueue_push(vq, elem, 0);
>> +virtio_notify(vdev, vq);
>> +g_free(elem);
>> +}
>> +}
>> +
> No offense, but I am a bit annoyed.
None taken at all.
> If you are going to copy my code
> you should at least keep up with the fixes.
Yeah I did refer to your code and just because the quality of your code is
better than what I posted earlier and there is quite a lot for me to learn from
it.
> stuff to handle the poison value. If you are going to just duplicate
> my setup you might as well have just pulled the QEMU patches from the
> last submission I did. Then this would have at least has the fix for
> the page poisoning.
>
The only reason I didn't include the poison change as I still need to understand
them.
I have this mentioned in my cover-email.
> Also it wouldn't hurt to mention that you are
> basing it off of the patch set I submitted since it hasn't been
> accepted yet.
My bad!! This I will surely do from next time.
>
>> static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
>> {
>> VirtIOBalloon *s = VIRTIO_BALLOON(vdev);
>> @@ -792,6 +825,12 @@ static void virtio_balloon_device_realize(DeviceState
>> *dev, Error **errp)
>> s->dvq = virtio_add_queue(vdev, 128, virtio_balloon_handle_output);
>> s->svq = virtio_add_queue(vdev, 128, virtio_balloon_receive_stats);
>>
>> +if (virtio_has_feature(s->host_features,
>> + VIRTIO_BALLOON_F_REPORTING)) {
>> +s->reporting_vq = virtio_add_queue(vdev, 16,
>> + virtio_balloon_handle_reporting);
>> +}
>> +
>> if (virtio_has_feature(s->host_features,
>> VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
>> s->free_page_vq = virtio_add_queue(vdev, VIRTQUEUE_MAX_SIZE,
>> @@ -912,6 +951,8 @@ static Property virtio_balloon_properties[] = {
>> * is disabled, resulting in QEMU 3.1 migration incompatibility. This
>> * property retains this quirk for QEMU 4.1 machine types.
>> */
>> +DEFINE_PROP_BIT("free-page-reporting", VirtIOBalloon, host_features,
>> +VIRTIO_BALLOON_F_REPORTING, true),
>> DEFINE_PROP_BOOL("qemu-4-0-config-size", VirtIOBalloon,
>> qemu_4_0_config_size, false),
>> DEFINE_PROP_LINK("iothread", VirtIOBalloon, iothread, TYPE_IOTHREAD,
>> diff --git a/include/hw/virtio/virtio-balloon.h
>> b/include/hw/virtio/virtio-balloon.h
>> index d1c968d237..15a05e6435 100644
>> --- a/
[virtio-dev] [QEMU Patch 2/2] virtio-balloon: support for handling page reporting
Page reporting is a feature which enables the virtual machine to report
chunk of free pages to the hypervisor.
This patch enables QEMU to process these reports from the VM and discard the
unused memory range.
Signed-off-by: Nitesh Narayan Lal
---
hw/virtio/virtio-balloon.c | 41 ++
include/hw/virtio/virtio-balloon.h | 2 +-
2 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index 25de154307..1132e47ee0 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -320,6 +320,39 @@ static void balloon_stats_set_poll_interval(Object *obj,
Visitor *v,
balloon_stats_change_timer(s, 0);
}
+static void virtio_balloon_handle_reporting(VirtIODevice *vdev, VirtQueue *vq)
+{
+VirtQueueElement *elem;
+
+while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement {
+unsigned int i;
+
+for (i = 0; i < elem->in_num; i++) {
+void *gaddr = elem->in_sg[i].iov_base;
+size_t size = elem->in_sg[i].iov_len;
+ram_addr_t ram_offset;
+size_t rb_page_size;
+ RAMBlock *rb;
+
+if (qemu_balloon_is_inhibited())
+continue;
+
+rb = qemu_ram_block_from_host(gaddr, false, _offset);
+rb_page_size = qemu_ram_pagesize(rb);
+
+/* For now we will simply ignore unaligned memory regions */
+if ((ram_offset | size) & (rb_page_size - 1))
+continue;
+
+ram_block_discard_range(rb, ram_offset, size);
+}
+
+virtqueue_push(vq, elem, 0);
+virtio_notify(vdev, vq);
+g_free(elem);
+}
+}
+
static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
{
VirtIOBalloon *s = VIRTIO_BALLOON(vdev);
@@ -792,6 +825,12 @@ static void virtio_balloon_device_realize(DeviceState
*dev, Error **errp)
s->dvq = virtio_add_queue(vdev, 128, virtio_balloon_handle_output);
s->svq = virtio_add_queue(vdev, 128, virtio_balloon_receive_stats);
+if (virtio_has_feature(s->host_features,
+ VIRTIO_BALLOON_F_REPORTING)) {
+s->reporting_vq = virtio_add_queue(vdev, 16,
+ virtio_balloon_handle_reporting);
+}
+
if (virtio_has_feature(s->host_features,
VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
s->free_page_vq = virtio_add_queue(vdev, VIRTQUEUE_MAX_SIZE,
@@ -912,6 +951,8 @@ static Property virtio_balloon_properties[] = {
* is disabled, resulting in QEMU 3.1 migration incompatibility. This
* property retains this quirk for QEMU 4.1 machine types.
*/
+DEFINE_PROP_BIT("free-page-reporting", VirtIOBalloon, host_features,
+VIRTIO_BALLOON_F_REPORTING, true),
DEFINE_PROP_BOOL("qemu-4-0-config-size", VirtIOBalloon,
qemu_4_0_config_size, false),
DEFINE_PROP_LINK("iothread", VirtIOBalloon, iothread, TYPE_IOTHREAD,
diff --git a/include/hw/virtio/virtio-balloon.h
b/include/hw/virtio/virtio-balloon.h
index d1c968d237..15a05e6435 100644
--- a/include/hw/virtio/virtio-balloon.h
+++ b/include/hw/virtio/virtio-balloon.h
@@ -42,7 +42,7 @@ enum virtio_balloon_free_page_report_status {
typedef struct VirtIOBalloon {
VirtIODevice parent_obj;
-VirtQueue *ivq, *dvq, *svq, *free_page_vq;
+VirtQueue *ivq, *dvq, *svq, *free_page_vq, *reporting_vq;
uint32_t free_page_report_status;
uint32_t num_pages;
uint32_t actual;
--
2.21.0
-
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] [QEMU Patch 1/2] virtio-balloon: adding bit for page reporting support
This patch will be replaced once the feature is merged into the Linux kernel. Signed-off-by: Nitesh Narayan Lal --- include/standard-headers/linux/virtio_balloon.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/standard-headers/linux/virtio_balloon.h b/include/standard-headers/linux/virtio_balloon.h index 9375ca2a70..1c5f6d6f2d 100644 --- a/include/standard-headers/linux/virtio_balloon.h +++ b/include/standard-headers/linux/virtio_balloon.h @@ -36,6 +36,7 @@ #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM2 /* Deflate balloon on OOM */ #define VIRTIO_BALLOON_F_FREE_PAGE_HINT3 /* VQ to report free pages */ #define VIRTIO_BALLOON_F_PAGE_POISON 4 /* Guest is using page poisoning */ +#define VIRTIO_BALLOON_F_REPORTING 5 /* Page reporting virtqueue */ /* Size of a PFN in the balloon interface. */ #define VIRTIO_BALLOON_PFN_SHIFT 12 -- 2.21.0 - 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] [RFC][PATCH v12 0/2] mm: Support for page reporting
This patch series proposes an efficient mechanism for reporting free memory from a guest to its hypervisor. It especially enables guests with no page cache (e.g., nvdimm, virtio-pmem) or with small page caches (e.g., ram > disk) to rapidly hand back free memory to the hypervisor. This approach has a minimal impact on the existing core-mm infrastructure. This approach tracks all freed pages of the order MAX_ORDER - 2 in bitmaps. A new hook after buddy merging is used to set the bits in the bitmap for a freed page. Each set bit is cleared after they are processed/checked for re-allocation. Bitmaps are stored on a per-zone basis and are protected by the zone lock. A workqueue asynchronously processes the bitmaps as soon as a pre-defined memory threshold is met, trying to isolate and report pages that are still free. The isolated pages are stored in a scatterlist and are reported via virtio-balloon, which is responsible for sending batched pages to the hypervisor. Once the hypervisor processed the reporting request, the isolated pages are returned back to the buddy. The thershold which defines the number of pages which will be isolated and reported to the hypervisor at a time is currently hardcoded to 16 in the guest. Benefit analysis: Number of 5 GB guests (each touching 4 to 5 GB memory) that can be launched on a 15 GB single NUMA system without using swap space in the host. Guest kernel--> Unmodified with v12 page reporting Number of guests--> 2 7 Conclusion: In a page-reporting enabled kernel, the guest is able to report most of its unused memory back to the host. Due to this on the same host, I was able to launch 7 guests without touching any swap compared to 2 which were launched with an unmodified kernel. Performance Analysis: In order to measure the performance impact of this patch-series over an unmodified kernel, I am using will-it-scale/page_fault1 on a 30 GB, 24 vcpus single NUMA guest which is affined to a single node in the host. Over several runs, I observed that with this patch-series there is a degradation of around 1-3% for certain cases. This degradation could be a result of page-zeroing overhead which comes with every page-fault in the guest. I also tried this test on a 2 NUMA node host running page reporting enabled 60GB guest also having 2 NUMA nodes and 24 vcpus. I observed a similar degradation of around 1-3% in most of the cases. For certain cases, the variability even with an unmodified kernel was around 4-6% with every fresh boot. I will continue to investigate this further to find the reason behind it. Ongoing work-items: * I have a working prototype for supporting memory hotplug/hotremove with page reporting. However, it still requires more testing and fixes specifically on the hotremove side. Right now, for any memory hotplug or hotremove request bitmap or its respective fields are not changed. Hence, memory added via hotplug is not tracked in the bitmap. Similarly, removed memory is not reported to the hypervisor by using an online memory check. * I will also have to look into the details about how to handle page poisoning scenarios and test with directly assigned devices. Changes from v11: https://lkml.org/lkml/2019/7/10/742 * Moved the fields required to manage bitmap of free pages to 'struct zone'. * Replaced the list which was used to hold and report the free pages with scatterlist. * Tried to fix the anti-kernel patterns and improve overall code quality. * Fixed a few bugs in the code which were reported in the last posting. * Moved to use MADV_DONTNEED from MADV_FREE. * Replaced page hinting in favor of page reporting. * Addressed other comments which I received in the last posting. Changes from v10: https://lkml.org/lkml/2019/6/3/943 * Added logic to take care of multiple NUMA nodes scenarios. * Simplified the logic for reporting isolated pages to the host. (Eg. replaced dynamically allocated arrays with static ones, introduced wait event instead of the loop in order to wait for a response from the host) * Added a mutex to prevent race condition when page reporting is enabled by multiple drivers. * Simplified the logic responsible for decrementing free page counter for each zone. * Simplified code structuring/naming. -- Nitesh Narayan Lal (2): mm: page_reporting: core infrastructure virtio-balloon: interface to support free page reporting drivers/virtio/Kconfig | 1 + drivers/virtio/virtio_balloon.c | 64 +- include/linux/mmzone.h | 11 + include/linux/page_reporting.h | 63 ++ include/uapi/linux/virtio_balloon.h | 1 + mm/Kconfig | 6 + mm/Makefile | 1 + mm/page_alloc.c | 42 +++- mm/page_reporting.c | 332 9 files changed, 513 insertions(+), 8 deletions(-) create mo
[virtio-dev] [RFC][Patch v12 2/2] virtio-balloon: interface to support free page reporting
Enables the kernel to negotiate VIRTIO_BALLOON_F_REPORTING feature with
the host. If it is available and page_reporting_flag is set to true,
page_reporting is enabled and its callback is configured along with
the max_pages count which indicates the maximum number of pages that
can be isolated and reported at a time. Currently, only free pages of
order >= (MAX_ORDER - 2) are reported. To prevent any false OOM
max_pages count is set to 16.
By default page_reporting feature is enabled and gets loaded as soon
as the virtio-balloon driver is loaded. However, it could be disabled
by writing the page_reporting_flag which is a virtio-balloon parameter.
Signed-off-by: Nitesh Narayan Lal
---
drivers/virtio/Kconfig | 1 +
drivers/virtio/virtio_balloon.c | 64 -
include/uapi/linux/virtio_balloon.h | 1 +
3 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 078615cf2afc..4b2dd8259ff5 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -58,6 +58,7 @@ config VIRTIO_BALLOON
tristate "Virtio balloon driver"
depends on VIRTIO
select MEMORY_BALLOON
+ select PAGE_REPORTING
---help---
This driver supports increasing and decreasing the amount
of memory within a KVM guest.
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 226fbb995fb0..defec00d4ee2 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
/*
* Balloon device works in 4K page units. So each page is pointed to by
@@ -46,6 +47,7 @@ enum virtio_balloon_vq {
VIRTIO_BALLOON_VQ_DEFLATE,
VIRTIO_BALLOON_VQ_STATS,
VIRTIO_BALLOON_VQ_FREE_PAGE,
+ VIRTIO_BALLOON_VQ_REPORTING,
VIRTIO_BALLOON_VQ_MAX
};
@@ -55,7 +57,8 @@ enum virtio_balloon_config_read {
struct virtio_balloon {
struct virtio_device *vdev;
- struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq;
+ struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq,
+*reporting_vq;
/* Balloon's own wq for cpu-intensive work items */
struct workqueue_struct *balloon_wq;
@@ -113,6 +116,9 @@ struct virtio_balloon {
/* To register a shrinker to shrink memory upon memory pressure */
struct shrinker shrinker;
+
+ /* To configure page reporting to report isolated pages */
+ struct page_reporting_config page_reporting_conf;
};
static struct virtio_device_id id_table[] = {
@@ -120,6 +126,10 @@ static struct virtio_device_id id_table[] = {
{ 0 },
};
+bool page_reporting_flag = true;
+module_param(page_reporting_flag, bool, 0644);
+MODULE_PARM_DESC(page_reporting_flag, "Enable page reporting");
+
static u32 page_to_balloon_pfn(struct page *page)
{
unsigned long pfn = page_to_pfn(page);
@@ -152,6 +162,44 @@ static void tell_host(struct virtio_balloon *vb, struct
virtqueue *vq)
}
+void virtballoon_report_pages(struct page_reporting_config
*page_reporting_conf,
+ unsigned int num_pages)
+{
+ struct virtio_balloon *vb = container_of(page_reporting_conf,
+struct virtio_balloon,
+page_reporting_conf);
+ struct virtqueue *vq = vb->reporting_vq;
+ int err, unused;
+
+ /* We should always be able to add these buffers to an empty queue. */
+ err = virtqueue_add_inbuf(vq, page_reporting_conf->sg, num_pages, vb,
+ GFP_NOWAIT);
+ /* We should not report if the guest is low on memory */
+ if (unlikely(err))
+ return;
+ virtqueue_kick(vq);
+
+ /* When host has read buffer, this completes via balloon_ack */
+ wait_event(vb->acked, virtqueue_get_buf(vq, ));
+}
+
+static void virtballoon_page_reporting_setup(struct virtio_balloon *vb)
+{
+ struct device *dev = >vdev->dev;
+ int err;
+
+ vb->page_reporting_conf.report = virtballoon_report_pages;
+ vb->page_reporting_conf.max_pages = PAGE_REPORTING_MAX_PAGES;
+ err = page_reporting_enable(>page_reporting_conf);
+ if (err < 0) {
+ dev_err(dev, "Failed to enable reporting, err = %d\n", err);
+ page_reporting_flag = false;
+ vb->page_reporting_conf.report = NULL;
+ vb->page_reporting_conf.max_pages = 0;
+ return;
+ }
+}
+
static void set_page_pfns(struct virtio_balloon *vb,
__virtio32 pfns[], struct page *page)
{
@@ -476,6 +524,7 @@ static int init_vqs(struct virtio_balloon *vb)
names[VIRTIO_BALLOON_VQ_DEFLATE] = "deflate";
names[VIRTIO_BALLOON_VQ_STA
[virtio-dev] [RFC][Patch v12 1/2] mm: page_reporting: core infrastructure
This patch introduces the core infrastructure for free page reporting in
virtual environments. It enables the kernel to track the free pages which
can be reported to its hypervisor so that the hypervisor could
free and reuse that memory as per its requirement.
While the pages are getting processed in the hypervisor (e.g.,
via MADV_DONTNEED), the guest must not use them, otherwise, data loss
would be possible. To avoid such a situation, these pages are
temporarily removed from the buddy. The amount of pages removed
temporarily from the buddy is governed by the backend(virtio-balloon
in our case).
To efficiently identify free pages that can to be reported to the
hypervisor, bitmaps in a coarse granularity are used. Only fairly big
chunks are reported to the hypervisor - especially, to not break up THP
in the hypervisor - "MAX_ORDER - 2" on x86, and to save space. The bits
in the bitmap are an indication whether a page *might* be free, not a
guarantee. A new hook after buddy merging sets the bits.
Bitmaps are stored per zone, protected by the zone lock. A workqueue
asynchronously processes the bitmaps, trying to isolate and report pages
that are still free. The backend (virtio-balloon) is responsible for
reporting these batched pages to the host synchronously. Once reporting/
freeing is complete, isolated pages are returned back to the buddy.
Signed-off-by: Nitesh Narayan Lal
---
include/linux/mmzone.h | 11 ++
include/linux/page_reporting.h | 63 +++
mm/Kconfig | 6 +
mm/Makefile| 1 +
mm/page_alloc.c| 42 -
mm/page_reporting.c| 332 +
6 files changed, 448 insertions(+), 7 deletions(-)
create mode 100644 include/linux/page_reporting.h
create mode 100644 mm/page_reporting.c
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index d77d717c620c..ba5f5b508f25 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -559,6 +559,17 @@ struct zone {
/* Zone statistics */
atomic_long_t vm_stat[NR_VM_ZONE_STAT_ITEMS];
atomic_long_t vm_numa_stat[NR_VM_NUMA_STAT_ITEMS];
+#ifdef CONFIG_PAGE_REPORTING
+ /* Pointer to the bitmap in PAGE_REPORTING_MIN_ORDER granularity */
+ unsigned long *bitmap;
+ /* Preserve start and end PFN in case they change due to hotplug */
+ unsigned long base_pfn;
+ unsigned long end_pfn;
+ /* Free pages of granularity PAGE_REPORTING_MIN_ORDER */
+ atomic_t free_pages;
+ /* Number of bits required in the bitmap */
+ unsigned long nbits;
+#endif
} cacheline_internodealigned_in_smp;
enum pgdat_flags {
diff --git a/include/linux/page_reporting.h b/include/linux/page_reporting.h
new file mode 100644
index ..37a39589939d
--- /dev/null
+++ b/include/linux/page_reporting.h
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_PAGE_REPORTING_H
+#define _LINUX_PAGE_REPORTING_H
+
+#define PAGE_REPORTING_MIN_ORDER (MAX_ORDER - 2)
+#define PAGE_REPORTING_MAX_PAGES 16
+
+#ifdef CONFIG_PAGE_REPORTING
+struct page_reporting_config {
+ /* function to hint batch of isolated pages */
+ void (*report)(struct page_reporting_config *phconf,
+ unsigned int num_pages);
+
+ /* scatterlist to hold the isolated pages to be hinted */
+ struct scatterlist *sg;
+
+ /*
+* Maxmimum pages that are going to be hinted to the hypervisor at a
+* time of granularity >= PAGE_REPORTING_MIN_ORDER.
+*/
+ int max_pages;
+
+ /* work object to process page reporting rqeuests */
+ struct work_struct reporting_work;
+
+ /* tracks the number of reporting request processed at a time */
+ atomic_t refcnt;
+};
+
+void __page_reporting_enqueue(struct page *page);
+void __return_isolated_page(struct zone *zone, struct page *page);
+void set_pageblock_migratetype(struct page *page, int migratetype);
+
+/**
+ * page_reporting_enqueue - checks the eligibility of the freed page based on
+ * its order for further page reporting processing.
+ * @page: page which has been freed.
+ * @order: order for the the free page.
+ */
+static inline void page_reporting_enqueue(struct page *page, int order)
+{
+ if (order < PAGE_REPORTING_MIN_ORDER)
+ return;
+ __page_reporting_enqueue(page);
+}
+
+int page_reporting_enable(struct page_reporting_config *phconf);
+void page_reporting_disable(struct page_reporting_config *phconf);
+#else
+static inline void page_reporting_enqueue(struct page *page, int order)
+{
+}
+
+static inline int page_reporting_enable(struct page_reporting_config *phconf)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline void page_reporting_disable(struct page_reporting_config *phconf)
+{
+}
+#endif /* CONFIG_PAGE_REPORTING */
+#endif /* _LINUX_PAGE_REPORTING_H */
diff --git a/mm/Kcon
