linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Atanasov <alexander.atanasov@virtuozzo.com>
To: David Hildenbrand <david@redhat.com>, Nadav Amit <nadav.amit@gmail.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	kernel@openvz.org,
	Linux Virtualization <virtualization@lists.linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>
Subject: Re: RFC [PATCH v4 2/7] Enable balloon drivers to report inflated memory
Date: Fri, 14 Oct 2022 17:10:10 +0300	[thread overview]
Message-ID: <7472d836-51af-d3b6-e4c3-8d9e7ea53c82@virtuozzo.com> (raw)
In-Reply-To: <7e6f2d09-e5cf-7f8d-965d-a39bfb0ea286@redhat.com>

Hello,

On 14.10.22 16:40, David Hildenbrand wrote:
>>>>
>>>> Other problem is that there are drivers that do not use
>>>> adjust_managed_page_count().
>>>
>>> Which ones? Do we care?
>>
>> VMWare and Virtio balloon drivers. I recently proposed to unify them and
>> the objection was that it would break existing users - which is valid so
>> we must care i guess.
> 
> I'm confused, I think we care about actual adjustment of the total pages 
> available here, that we want to notify the system about. These 
> approaches (vmware, virtio-balloon with deflate-on-oom) don't adjust 
> totalpages, because the assumption is that we can get back the inflated 
> memory any time we really need it automatically.

We want to notify about the actual adjustment of available pages no 
matter where they are accounted free or total. Users don't care where 
the ram came from or has gone. They need the total change, so they can 
decided if they need to recalculate.

The example i wrote earlier:
Kernel boots with 4GB.
Balloon takes back 2GB.
epoll_events allocated 4% of the total memory at boot.
For simpler math after total ram is reduced to 2GB, that 4% become 
really 8% of the total ram.
We want to tell epoll that there is 2GB change in total ram, so it can 
update to really use 4%.

Reverse direction is true too - you hot plug 4GB and the 4% become just 
2% so you are not using newly available ram optimally.

And it is not only about epoll.

When not recalculated/updated this allocations/limits/etc the balance of 
memory usage between userspace and kernel gets a bit off, and i think 
not a bit but a way off.

About the assumption drivers can get back the ram at anytime - if they 
use the oom_notifier - they can update the totalpages without problem. 
oom_killer doesn't check totalram_pages() but tries to free memory with 
the notifier and only if it fails totalram_pages() is consulted.

-- 
Regards,
Alexander Atanasov



      reply	other threads:[~2022-10-14 14:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20221005090158.2801592-1-alexander.atanasov@virtuozzo.com>
2022-10-05  9:01 ` [PATCH v4 1/7] Make place for common balloon code Alexander Atanasov
2022-10-05  9:01 ` [PATCH v4 2/7] Enable balloon drivers to report inflated memory Alexander Atanasov
2022-10-05 17:25   ` Nadav Amit
2022-10-06  7:34     ` Alexander Atanasov
2022-10-06 21:07       ` Nadav Amit
2022-10-07 10:58         ` RFC " Alexander Atanasov
2022-10-10  6:18           ` Nadav Amit
2022-10-10  7:24             ` Alexander Atanasov
2022-10-10 14:47               ` Nadav Amit
2022-10-11  9:07                 ` Alexander Atanasov
2022-10-11  9:23                   ` David Hildenbrand
2022-10-14 12:50                     ` Alexander Atanasov
2022-10-14 13:01                       ` David Hildenbrand
2022-10-14 13:33                         ` Alexander Atanasov
2022-10-14 13:40                           ` David Hildenbrand
2022-10-14 14:10                             ` Alexander Atanasov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7472d836-51af-d3b6-e4c3-8d9e7ea53c82@virtuozzo.com \
    --to=alexander.atanasov@virtuozzo.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=kernel@openvz.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mst@redhat.com \
    --cc=nadav.amit@gmail.com \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox