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
