Thread (24 messages) flat view 24 messages, 3 authors, 2020-01-22

Re: [PATCH RFC v1] mm: is_mem_section_removable() overhaul

From: David Hildenbrand <hidden>
Date: 2020-01-22 10:54:19
Also in: linux-mm, lkml

On 22.01.20 11:42, Michal Hocko wrote:
On Wed 22-01-20 11:39:08, David Hildenbrand wrote:
quoted
quoted
quoted
quoted
Really, the interface is flawed and should have never been merged in the
first place. We cannot simply remove it altogether I am afraid so let's
at least remove the bogus code and pretend that the world is a better
place where everything is removable except the reality sucks...
As I expressed already, the interface works as designed/documented and
has been used like that for years.
It seems we do differ in the usefulness though. Using a crappy interface
for years doesn't make it less crappy. I do realize we cannot remove the
interface but we can remove issues with the implementation and I dare to
say that most existing users wouldn't really notice.
Well, at least powerpc-utils (why this interface was introduced) will
notice a) performance wise and b) because more logging output will be
generated (obviously non-offlineable blocks will be tried to offline).
I would really appreciate some specific example for a real usecase. I am
not familiar with powerpc-utils worklflows myself.
Not an expert myself:

https://github.com/ibm-power-utilities/powerpc-utils

-> src/drmgr/drslot_chrp_mem.c

On request to remove some memory it will

a) Read "->removable" of all memory blocks ("lmb")
b) Check if the request can be fulfilled using the removable blocks
c) Try to offline the memory blocks by trying to offline it. If that
succeeded, trigger removeal of it using some hypervisor hooks.

Interestingly, with "AMS ballooning", it will already consider the
"removable" information useless (most probably, because of
non-migratable balloon pages that can be offlined - I assume the powerpc
code that I converted to proper balloon compaction just recently). a)
and b) is skipped.

Returning "yes" on all blocks will make them handle it just like if "AMS
ballooning" is active. So any memory block will be tried. Should work
but will be slower if no ballooning is active.

-- 
Thanks,

David / dhildenb
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help