On 07/18/2019 12:13 PM, Michael S. Tsirkin wrote:
It makes sense for pages in the balloon (requested by hypervisor).
However free page hinting can freeze up lots of memory for its own
internal reasons. It does not make sense to ask hypervisor
to set flags in order to fix internal guest issues.
Sounds reasonable to me. Probably we could move the flag check to
shrinker_count and shrinker_scan as a reclaiming condition for
ballooning pages only?
Right. But that does not include the pages in the hint vq,
which could be a significant amount of memory.
I think it includes, as vb->num_free_page_blocks records the total number
of free page blocks that balloon has taken from mm.
For shrink_free_pages, it calls return_free_pages_to_mm, which pops pages
from vb->free_page_list (this is the list where pages get enlisted after
they
are put to the hint vq, see get_free_page_and_send).
- if free pages are being reported, pages freed
by shrinker will just get re-allocated again
fill_balloon will re-try the allocation after sleeping 200ms once allocation fails.
Even if ballon was never inflated, if shrinker frees some memory while
we are hinting, hint vq will keep going and allocate it back without
sleeping.
Still see get_free_page_and_send. -EINTR is returned when page
allocation fails,
and reporting ends then.
Shrinker is called on system memory pressure. On memory pressure
get_free_page_and_send will fail memory allocation, so it stops
allocating more.
Best,
Wei
