* [LSF/MM/BPF TOPIC] VM Memory Overcommit
@ 2023-02-22 23:59 T.J. Alumbaugh
2023-02-28 6:02 ` Gupta, Pankaj
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: T.J. Alumbaugh @ 2023-02-22 23:59 UTC (permalink / raw)
To: lsf-pc
Cc: Sudarshan Rajagopalan (QUIC),
hch, kai.huang, David Hildenbrand, jon, Yuanchu Xie, linux-mm
Hi,
This topic proposal would be to present and discuss multiple MM
features to improve host memory overcommit while running VMs. There
are two general cases:
1. The host and its guests operate independently,
2. The host and its guests cooperate by techniques like ballooning.
In the first case, we would discuss some new techniques, e.g., fast
access bit harvesting in the KVM MMU, and some difficulties, e.g.,
double zswapping.
In the second case, we would like to discuss a novel working set size
(WSS) notifier framework and some improvements to the ballooning
policy. The WSS notifier, when available, can report WSS to its
listeners. VM Memory Overcommit is one of its use cases: the
virtio-balloon driver can register for WSS notifications and relay WSS
to the host. The host can leverage the WSS notifications and improve
the ballooning policy.
This topic would be of interest to a wide range of audience, e.g.,
phones, laptops and servers.
Co-presented with Yuanchu Xie.
Thanks,
-T.J.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [LSF/MM/BPF TOPIC] VM Memory Overcommit
2023-02-22 23:59 [LSF/MM/BPF TOPIC] VM Memory Overcommit T.J. Alumbaugh
@ 2023-02-28 6:02 ` Gupta, Pankaj
2023-03-01 3:09 ` T.J. Alumbaugh
2023-02-28 9:20 ` David Hildenbrand
2023-05-19 21:39 ` T.J. Alumbaugh
2 siblings, 1 reply; 10+ messages in thread
From: Gupta, Pankaj @ 2023-02-28 6:02 UTC (permalink / raw)
To: T.J. Alumbaugh, lsf-pc
Cc: Sudarshan Rajagopalan (QUIC),
hch, kai.huang, David Hildenbrand, jon, Yuanchu Xie, linux-mm
Hi T.J,
> This topic proposal would be to present and discuss multiple MM
> features to improve host memory overcommit while running VMs. There
> are two general cases:
>
> 1. The host and its guests operate independently,
>
> 2. The host and its guests cooperate by techniques like ballooning.
>
> In the first case, we would discuss some new techniques, e.g., fast
> access bit harvesting in the KVM MMU, and some difficulties, e.g.,
> double zswapping.
>
> In the second case, we would like to discuss a novel working set size
> (WSS) notifier framework and some improvements to the ballooning
> policy. The WSS notifier, when available, can report WSS to its
> listeners. VM Memory Overcommit is one of its use cases: the
> virtio-balloon driver can register for WSS notifications and relay WSS
> to the host. The host can leverage the WSS notifications and improve
> the ballooning policy.
I am interested in this discussion. Have few questions below:
- What kind/frequency of data we expect WSS would relay to the host in
good and worst case?
- Thoughts already considered about the overhead VM will have based on
WSS relay data to the host and host taking action on the data?
-- One thing iirc from the free page hinting design experiments is
preventing guest and host acting simultaneously (e.g for free) on
same page (pfn) and also reducing the overhead of sending data from
guest to host by sending the highest possible page order.
Maybe some of these or other similar techniques are already considered.
Thanks,
Pankaj
>
> This topic would be of interest to a wide range of audience, e.g.,
> phones, laptops and servers.
> Co-presented with Yuanchu Xie.
>
> Thanks,
>
> -T.J.
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [LSF/MM/BPF TOPIC] VM Memory Overcommit
2023-02-22 23:59 [LSF/MM/BPF TOPIC] VM Memory Overcommit T.J. Alumbaugh
2023-02-28 6:02 ` Gupta, Pankaj
@ 2023-02-28 9:20 ` David Hildenbrand
2023-02-28 22:38 ` SeongJae Park
2023-03-01 3:21 ` T.J. Alumbaugh
2023-05-19 21:39 ` T.J. Alumbaugh
2 siblings, 2 replies; 10+ messages in thread
From: David Hildenbrand @ 2023-02-28 9:20 UTC (permalink / raw)
To: T.J. Alumbaugh, lsf-pc
Cc: Sudarshan Rajagopalan (QUIC), hch, kai.huang, jon, Yuanchu Xie, linux-mm
On 23.02.23 00:59, T.J. Alumbaugh wrote:
> Hi,
>
> This topic proposal would be to present and discuss multiple MM
> features to improve host memory overcommit while running VMs. There
> are two general cases:
>
> 1. The host and its guests operate independently,
>
> 2. The host and its guests cooperate by techniques like ballooning.
>
> In the first case, we would discuss some new techniques, e.g., fast
> access bit harvesting in the KVM MMU, and some difficulties, e.g.,
> double zswapping.
>
> In the second case, we would like to discuss a novel working set size
> (WSS) notifier framework and some improvements to the ballooning
> policy. The WSS notifier, when available, can report WSS to its
> listeners. VM Memory Overcommit is one of its use cases: the
> virtio-balloon driver can register for WSS notifications and relay WSS
> to the host. The host can leverage the WSS notifications and improve
> the ballooning policy.
>
> This topic would be of interest to a wide range of audience, e.g.,
> phones, laptops and servers.
> Co-presented with Yuanchu Xie.
In general, having the WSS available to the hypervisor might be
beneficial. I recall, that there was an idea to leverage MGLRU and to
communicate MGLRU statistics to the hypervisor, such that the hypervisor
can make decisions using these statistics.
But note that I don't think that the future will be traditional memory
balloon inflation/deflation. I think it might be useful in related
context, though.
What we actually might want is a way to tell the OS ruining inside the
VM to "please try not using more than XXX MiB of physical memory" but
treat it as a soft limit. So in case we mess up, or there is a sudden
peak in memory consumption due to a workload, we won't harm the guest
OS/workload, and don't have to act immediately to avoid trouble. One can
think of it like an evolution of memory ballooning: instead of creating
artificial memory pressure by inflating the balloon that is fairly event
driven and requires explicit memory deflation, we teach the OS to do it
natively and pair it with free page reporting.
All free physical memory inside the VM can be reported using free page
reporting to the hypervisor, and the OS will try sticking to the
requested "logical" VM size, unless there is real demand for more memory.
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [LSF/MM/BPF TOPIC] VM Memory Overcommit
2023-02-28 9:20 ` David Hildenbrand
@ 2023-02-28 22:38 ` SeongJae Park
2023-02-28 22:52 ` David Hildenbrand
2023-03-01 3:21 ` T.J. Alumbaugh
1 sibling, 1 reply; 10+ messages in thread
From: SeongJae Park @ 2023-02-28 22:38 UTC (permalink / raw)
To: David Hildenbrand
Cc: T.J. Alumbaugh, lsf-pc, Sudarshan Rajagopalan (QUIC),
hch, kai.huang, jon, Yuanchu Xie, linux-mm, damon
On Tue, 28 Feb 2023 10:20:57 +0100 David Hildenbrand <david@redhat.com> wrote:
> On 23.02.23 00:59, T.J. Alumbaugh wrote:
> > Hi,
> >
> > This topic proposal would be to present and discuss multiple MM
> > features to improve host memory overcommit while running VMs. There
> > are two general cases:
> >
> > 1. The host and its guests operate independently,
> >
> > 2. The host and its guests cooperate by techniques like ballooning.
> >
> > In the first case, we would discuss some new techniques, e.g., fast
> > access bit harvesting in the KVM MMU, and some difficulties, e.g.,
> > double zswapping.
> >
> > In the second case, we would like to discuss a novel working set size
> > (WSS) notifier framework and some improvements to the ballooning
> > policy. The WSS notifier, when available, can report WSS to its
> > listeners. VM Memory Overcommit is one of its use cases: the
> > virtio-balloon driver can register for WSS notifications and relay WSS
> > to the host. The host can leverage the WSS notifications and improve
> > the ballooning policy.
> >
> > This topic would be of interest to a wide range of audience, e.g.,
> > phones, laptops and servers.
> > Co-presented with Yuanchu Xie.
>
> In general, having the WSS available to the hypervisor might be
> beneficial. I recall, that there was an idea to leverage MGLRU and to
> communicate MGLRU statistics to the hypervisor, such that the hypervisor
> can make decisions using these statistics.
>
> But note that I don't think that the future will be traditional memory
> balloon inflation/deflation. I think it might be useful in related
> context, though.
>
> What we actually might want is a way to tell the OS ruining inside the
> VM to "please try not using more than XXX MiB of physical memory" but
> treat it as a soft limit. So in case we mess up, or there is a sudden
> peak in memory consumption due to a workload, we won't harm the guest
> OS/workload, and don't have to act immediately to avoid trouble. One can
> think of it like an evolution of memory ballooning: instead of creating
> artificial memory pressure by inflating the balloon that is fairly event
> driven and requires explicit memory deflation, we teach the OS to do it
> natively and pair it with free page reporting.
>
> All free physical memory inside the VM can be reported using free page
> reporting to the hypervisor, and the OS will try sticking to the
> requested "logical" VM size, unless there is real demand for more memory.
I think use of DAMON_RECLAIM[1] inside VM together with free pages reporting
could be an option. Some users tried that in a manual way and reported some
positive results. I'm trying to find a good way to provide some control of the
in-VM DAMON_RECLAIM utilization to hypervisor.
Hope to attend this session and discuss about that together.
[1] https://docs.kernel.org/admin-guide/mm/damon/reclaim.html
Thanks,
SJ
>
> --
> Thanks,
>
> David / dhildenb
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [LSF/MM/BPF TOPIC] VM Memory Overcommit
2023-02-28 22:38 ` SeongJae Park
@ 2023-02-28 22:52 ` David Hildenbrand
2023-03-02 3:26 ` David Rientjes
0 siblings, 1 reply; 10+ messages in thread
From: David Hildenbrand @ 2023-02-28 22:52 UTC (permalink / raw)
To: SeongJae Park
Cc: T.J. Alumbaugh, lsf-pc, Sudarshan Rajagopalan (QUIC),
hch, kai.huang, jon, Yuanchu Xie, linux-mm, damon
On 28.02.23 23:38, SeongJae Park wrote:
> On Tue, 28 Feb 2023 10:20:57 +0100 David Hildenbrand <david@redhat.com> wrote:
>
>> On 23.02.23 00:59, T.J. Alumbaugh wrote:
>>> Hi,
>>>
>>> This topic proposal would be to present and discuss multiple MM
>>> features to improve host memory overcommit while running VMs. There
>>> are two general cases:
>>>
>>> 1. The host and its guests operate independently,
>>>
>>> 2. The host and its guests cooperate by techniques like ballooning.
>>>
>>> In the first case, we would discuss some new techniques, e.g., fast
>>> access bit harvesting in the KVM MMU, and some difficulties, e.g.,
>>> double zswapping.
>>>
>>> In the second case, we would like to discuss a novel working set size
>>> (WSS) notifier framework and some improvements to the ballooning
>>> policy. The WSS notifier, when available, can report WSS to its
>>> listeners. VM Memory Overcommit is one of its use cases: the
>>> virtio-balloon driver can register for WSS notifications and relay WSS
>>> to the host. The host can leverage the WSS notifications and improve
>>> the ballooning policy.
>>>
>>> This topic would be of interest to a wide range of audience, e.g.,
>>> phones, laptops and servers.
>>> Co-presented with Yuanchu Xie.
>>
>> In general, having the WSS available to the hypervisor might be
>> beneficial. I recall, that there was an idea to leverage MGLRU and to
>> communicate MGLRU statistics to the hypervisor, such that the hypervisor
>> can make decisions using these statistics.
>>
>> But note that I don't think that the future will be traditional memory
>> balloon inflation/deflation. I think it might be useful in related
>> context, though.
>>
>> What we actually might want is a way to tell the OS ruining inside the
>> VM to "please try not using more than XXX MiB of physical memory" but
>> treat it as a soft limit. So in case we mess up, or there is a sudden
>> peak in memory consumption due to a workload, we won't harm the guest
>> OS/workload, and don't have to act immediately to avoid trouble. One can
>> think of it like an evolution of memory ballooning: instead of creating
>> artificial memory pressure by inflating the balloon that is fairly event
>> driven and requires explicit memory deflation, we teach the OS to do it
>> natively and pair it with free page reporting.
>>
>> All free physical memory inside the VM can be reported using free page
>> reporting to the hypervisor, and the OS will try sticking to the
>> requested "logical" VM size, unless there is real demand for more memory.
>
> I think use of DAMON_RECLAIM[1] inside VM together with free pages reporting
> could be an option. Some users tried that in a manual way and reported some
> positive results. I'm trying to find a good way to provide some control of the
> in-VM DAMON_RECLAIM utilization to hypervisor.
>
I think we might want to go one step further and not only reclaim
(pro)actively, but also limit e.g., the growth of caches, such as the
pagecache, to make them also aware of a soft-limit. Having that said, I
still have to learn more about DAMON reclaim :)
> Hope to attend this session and discuss about that together.
Absolutely!
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [LSF/MM/BPF TOPIC] VM Memory Overcommit
2023-02-28 6:02 ` Gupta, Pankaj
@ 2023-03-01 3:09 ` T.J. Alumbaugh
0 siblings, 0 replies; 10+ messages in thread
From: T.J. Alumbaugh @ 2023-03-01 3:09 UTC (permalink / raw)
To: Gupta, Pankaj
Cc: lsf-pc, Sudarshan Rajagopalan (QUIC),
hch, kai.huang, David Hildenbrand, jon, Yuanchu Xie, linux-mm
Hi Pankaj,
On Mon, Feb 27, 2023 at 11:02 PM Gupta, Pankaj <pankaj.gupta@amd.com> wrote:
>
>
> - What kind/frequency of data we expect WSS would relay to the host in
> good and worst case?
>
This is a good question. Right now, we communicate a histogram of page
counts (not very much data) during periods of memory pressure, with
user configurable rate limiting. The goal is to notify when it's
important to take action, but we also allow the host to request a
report.
> - Thoughts already considered about the overhead VM will have based on
> WSS relay data to the host and host taking action on the data?
>
> -- One thing iirc from the free page hinting design experiments is
> preventing guest and host acting simultaneously (e.g for free) on
> same page (pfn) and also reducing the overhead of sending data from
> guest to host by sending the highest possible page order.
>
I think you are correct that the best way to reduce overhead is by
sending the highest possible page order. So far we have not directly
addressed this problem. The goal here is to solve the "when" and "how
much" problems for balloon adjustment, which will go far in minimizing
fragmentation caused by frequent balloon adjustments. But it seems
clear that sending a higher page order is important too.
> Maybe some of these or other similar techniques are already considered.
>
David's idea of pairing this capability with free page reporting (in
the next reply on this thread) seems like an intriguing next step.
-T.J.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [LSF/MM/BPF TOPIC] VM Memory Overcommit
2023-02-28 9:20 ` David Hildenbrand
2023-02-28 22:38 ` SeongJae Park
@ 2023-03-01 3:21 ` T.J. Alumbaugh
1 sibling, 0 replies; 10+ messages in thread
From: T.J. Alumbaugh @ 2023-03-01 3:21 UTC (permalink / raw)
To: David Hildenbrand
Cc: Sudarshan Rajagopalan (QUIC), hch, kai.huang, jon, Yuanchu Xie, linux-mm
On Tue, Feb 28, 2023 at 2:21 AM David Hildenbrand <david@redhat.com> wrote:
>
> What we actually might want is a way to tell the OS ruining inside the
> VM to "please try not using more than XXX MiB of physical memory" but
> treat it as a soft limit. So in case we mess up, or there is a sudden
> peak in memory consumption due to a workload, we won't harm the guest
> OS/workload, and don't have to act immediately to avoid trouble. One can
> think of it like an evolution of memory ballooning: instead of creating
> artificial memory pressure by inflating the balloon that is fairly event
> driven and requires explicit memory deflation, we teach the OS to do it
> natively and pair it with free page reporting.
That's interesting. In our forthcoming balloon spec for this feature,
we provide a way to send such data from the host to the guest. We call
the general mechanism "notifications" right now, but we did not think
of that use case so far.
>
> All free physical memory inside the VM can be reported using free page
> reporting to the hypervisor, and the OS will try sticking to the
> requested "logical" VM size, unless there is real demand for more memory.
>
Yes, the two mechanisms can definitely work in tandem for such a use
case, although we have not tried that yet. Thanks for these ideas.
-T.J.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [LSF/MM/BPF TOPIC] VM Memory Overcommit
2023-02-28 22:52 ` David Hildenbrand
@ 2023-03-02 3:26 ` David Rientjes
2023-03-02 9:32 ` David Hildenbrand
0 siblings, 1 reply; 10+ messages in thread
From: David Rientjes @ 2023-03-02 3:26 UTC (permalink / raw)
To: David Hildenbrand
Cc: SeongJae Park, T.J. Alumbaugh, lsf-pc,
Sudarshan Rajagopalan (QUIC),
hch, kai.huang, jon, Yuanchu Xie, linux-mm, damon
On Tue, 28 Feb 2023, David Hildenbrand wrote:
> On 28.02.23 23:38, SeongJae Park wrote:
> > On Tue, 28 Feb 2023 10:20:57 +0100 David Hildenbrand <david@redhat.com>
> > wrote:
> >
> > > On 23.02.23 00:59, T.J. Alumbaugh wrote:
> > > > Hi,
> > > >
> > > > This topic proposal would be to present and discuss multiple MM
> > > > features to improve host memory overcommit while running VMs. There
> > > > are two general cases:
> > > >
> > > > 1. The host and its guests operate independently,
> > > >
> > > > 2. The host and its guests cooperate by techniques like ballooning.
> > > >
> > > > In the first case, we would discuss some new techniques, e.g., fast
> > > > access bit harvesting in the KVM MMU, and some difficulties, e.g.,
> > > > double zswapping.
> > > >
> > > > In the second case, we would like to discuss a novel working set size
> > > > (WSS) notifier framework and some improvements to the ballooning
> > > > policy. The WSS notifier, when available, can report WSS to its
> > > > listeners. VM Memory Overcommit is one of its use cases: the
> > > > virtio-balloon driver can register for WSS notifications and relay WSS
> > > > to the host. The host can leverage the WSS notifications and improve
> > > > the ballooning policy.
> > > >
> > > > This topic would be of interest to a wide range of audience, e.g.,
> > > > phones, laptops and servers.
> > > > Co-presented with Yuanchu Xie.
> > >
> > > In general, having the WSS available to the hypervisor might be
> > > beneficial. I recall, that there was an idea to leverage MGLRU and to
> > > communicate MGLRU statistics to the hypervisor, such that the hypervisor
> > > can make decisions using these statistics.
> > >
> > > But note that I don't think that the future will be traditional memory
> > > balloon inflation/deflation. I think it might be useful in related
> > > context, though.
> > >
> > > What we actually might want is a way to tell the OS ruining inside the
> > > VM to "please try not using more than XXX MiB of physical memory" but
> > > treat it as a soft limit. So in case we mess up, or there is a sudden
> > > peak in memory consumption due to a workload, we won't harm the guest
> > > OS/workload, and don't have to act immediately to avoid trouble. One can
> > > think of it like an evolution of memory ballooning: instead of creating
> > > artificial memory pressure by inflating the balloon that is fairly event
> > > driven and requires explicit memory deflation, we teach the OS to do it
> > > natively and pair it with free page reporting.
> > >
> > > All free physical memory inside the VM can be reported using free page
> > > reporting to the hypervisor, and the OS will try sticking to the
> > > requested "logical" VM size, unless there is real demand for more memory.
> >
> > I think use of DAMON_RECLAIM[1] inside VM together with free pages reporting
> > could be an option. Some users tried that in a manual way and reported some
> > positive results. I'm trying to find a good way to provide some control of
> > the
> > in-VM DAMON_RECLAIM utilization to hypervisor.
> >
>
> I think we might want to go one step further and not only reclaim
> (pro)actively, but also limit e.g., the growth of caches, such as the
> pagecache, to make them also aware of a soft-limit. Having that said, I still
> have to learn more about DAMON reclaim :)
>
I'm curious, is this limitation possible to impose with memcg today or are
specifically looking to provide a cap on page cache, dentries, inodes,
etc, without specifically requiring memcg?
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [LSF/MM/BPF TOPIC] VM Memory Overcommit
2023-03-02 3:26 ` David Rientjes
@ 2023-03-02 9:32 ` David Hildenbrand
0 siblings, 0 replies; 10+ messages in thread
From: David Hildenbrand @ 2023-03-02 9:32 UTC (permalink / raw)
To: David Rientjes
Cc: SeongJae Park, T.J. Alumbaugh, lsf-pc,
Sudarshan Rajagopalan (QUIC),
hch, kai.huang, jon, Yuanchu Xie, linux-mm, damon
On 02.03.23 04:26, David Rientjes wrote:
> On Tue, 28 Feb 2023, David Hildenbrand wrote:
>
>> On 28.02.23 23:38, SeongJae Park wrote:
>>> On Tue, 28 Feb 2023 10:20:57 +0100 David Hildenbrand <david@redhat.com>
>>> wrote:
>>>
>>>> On 23.02.23 00:59, T.J. Alumbaugh wrote:
>>>>> Hi,
>>>>>
>>>>> This topic proposal would be to present and discuss multiple MM
>>>>> features to improve host memory overcommit while running VMs. There
>>>>> are two general cases:
>>>>>
>>>>> 1. The host and its guests operate independently,
>>>>>
>>>>> 2. The host and its guests cooperate by techniques like ballooning.
>>>>>
>>>>> In the first case, we would discuss some new techniques, e.g., fast
>>>>> access bit harvesting in the KVM MMU, and some difficulties, e.g.,
>>>>> double zswapping.
>>>>>
>>>>> In the second case, we would like to discuss a novel working set size
>>>>> (WSS) notifier framework and some improvements to the ballooning
>>>>> policy. The WSS notifier, when available, can report WSS to its
>>>>> listeners. VM Memory Overcommit is one of its use cases: the
>>>>> virtio-balloon driver can register for WSS notifications and relay WSS
>>>>> to the host. The host can leverage the WSS notifications and improve
>>>>> the ballooning policy.
>>>>>
>>>>> This topic would be of interest to a wide range of audience, e.g.,
>>>>> phones, laptops and servers.
>>>>> Co-presented with Yuanchu Xie.
>>>>
>>>> In general, having the WSS available to the hypervisor might be
>>>> beneficial. I recall, that there was an idea to leverage MGLRU and to
>>>> communicate MGLRU statistics to the hypervisor, such that the hypervisor
>>>> can make decisions using these statistics.
>>>>
>>>> But note that I don't think that the future will be traditional memory
>>>> balloon inflation/deflation. I think it might be useful in related
>>>> context, though.
>>>>
>>>> What we actually might want is a way to tell the OS ruining inside the
>>>> VM to "please try not using more than XXX MiB of physical memory" but
>>>> treat it as a soft limit. So in case we mess up, or there is a sudden
>>>> peak in memory consumption due to a workload, we won't harm the guest
>>>> OS/workload, and don't have to act immediately to avoid trouble. One can
>>>> think of it like an evolution of memory ballooning: instead of creating
>>>> artificial memory pressure by inflating the balloon that is fairly event
>>>> driven and requires explicit memory deflation, we teach the OS to do it
>>>> natively and pair it with free page reporting.
>>>>
>>>> All free physical memory inside the VM can be reported using free page
>>>> reporting to the hypervisor, and the OS will try sticking to the
>>>> requested "logical" VM size, unless there is real demand for more memory.
>>>
>>> I think use of DAMON_RECLAIM[1] inside VM together with free pages reporting
>>> could be an option. Some users tried that in a manual way and reported some
>>> positive results. I'm trying to find a good way to provide some control of
>>> the
>>> in-VM DAMON_RECLAIM utilization to hypervisor.
>>>
>>
>> I think we might want to go one step further and not only reclaim
>> (pro)actively, but also limit e.g., the growth of caches, such as the
>> pagecache, to make them also aware of a soft-limit. Having that said, I still
>> have to learn more about DAMON reclaim :)
>>
>
> I'm curious, is this limitation possible to impose with memcg today or are
> specifically looking to provide a cap on page cache, dentries, inodes,
> etc, without specifically requiring memcg?
Good question, I remember the last time that topic was raised, the
common understanding was that existing mechanisms (i.e., memcg) were not
sufficient. But I am no expert on this, so this sure sounds like a good
topic to discuss in a bigger group, with hopefully some memcg experts
around :)
--
Thanks,
David / dhildenb
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [LSF/MM/BPF TOPIC] VM Memory Overcommit
2023-02-22 23:59 [LSF/MM/BPF TOPIC] VM Memory Overcommit T.J. Alumbaugh
2023-02-28 6:02 ` Gupta, Pankaj
2023-02-28 9:20 ` David Hildenbrand
@ 2023-05-19 21:39 ` T.J. Alumbaugh
2 siblings, 0 replies; 10+ messages in thread
From: T.J. Alumbaugh @ 2023-05-19 21:39 UTC (permalink / raw)
To: lsf-pc
Cc: Sudarshan Rajagopalan (QUIC),
hch, kai.huang, David Hildenbrand, jon, Yuanchu Xie, linux-mm
[-- Attachment #1.1: Type: text/plain, Size: 1259 bytes --]
On Wed, Feb 22, 2023 at 4:59 PM T.J. Alumbaugh <talumbau@google.com> wrote:
> Hi,
>
> This topic proposal would be to present and discuss multiple MM
> features to improve host memory overcommit while running VMs. There
> are two general cases:
>
> 1. The host and its guests operate independently,
>
> 2. The host and its guests cooperate by techniques like ballooning.
>
> In the first case, we would discuss some new techniques, e.g., fast
> access bit harvesting in the KVM MMU, and some difficulties, e.g.,
> double zswapping.
>
> In the second case, we would like to discuss a novel working set size
> (WSS) notifier framework and some improvements to the ballooning
> policy. The WSS notifier, when available, can report WSS to its
> listeners. VM Memory Overcommit is one of its use cases: the
> virtio-balloon driver can register for WSS notifications and relay WSS
> to the host. The host can leverage the WSS notifications and improve
> the ballooning policy.
>
> This topic would be of interest to a wide range of audience, e.g.,
> phones, laptops and servers.
> Co-presented with Yuanchu Xie.
>
> Thanks,
>
> -T.J.
>
For completeness, the slide deck that Yuanchu and I presented for this
topic is attached.
[-- Attachment #1.2: Type: text/html, Size: 1662 bytes --]
[-- Attachment #2: LSF_MM_BPF2023_Memory_Overcommit_in_Containerized_Environments.pdf --]
[-- Type: application/pdf, Size: 233345 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2023-05-19 21:40 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-22 23:59 [LSF/MM/BPF TOPIC] VM Memory Overcommit T.J. Alumbaugh
2023-02-28 6:02 ` Gupta, Pankaj
2023-03-01 3:09 ` T.J. Alumbaugh
2023-02-28 9:20 ` David Hildenbrand
2023-02-28 22:38 ` SeongJae Park
2023-02-28 22:52 ` David Hildenbrand
2023-03-02 3:26 ` David Rientjes
2023-03-02 9:32 ` David Hildenbrand
2023-03-01 3:21 ` T.J. Alumbaugh
2023-05-19 21:39 ` T.J. Alumbaugh
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.