linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux MM <linux-mm@kvack.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Leonardo Bras <leonardo@linux.ibm.com>,
	Nathan Lynch <nathanl@linux.ibm.com>,
	Allison Randal <allison@lohutok.net>,
	Nathan Fontenot <nfont@linux.vnet.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	lantianyu1986@gmail.com,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH RFC v1] mm: is_mem_section_removable() overhaul
Date: Wed, 22 Jan 2020 11:54:05 +0100	[thread overview]
Message-ID: <98b6c208-b4dd-9052-43f6-543068c649cc@redhat.com> (raw)
In-Reply-To: <20200122104230.GU29276@dhcp22.suse.cz>

On 22.01.20 11:42, Michal Hocko wrote:
> On Wed 22-01-20 11:39:08, David Hildenbrand wrote:
>>>>> 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


  reply	other threads:[~2020-01-22 10:54 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-17 10:57 [PATCH RFC v1] mm: is_mem_section_removable() overhaul David Hildenbrand
2020-01-17 11:33 ` Michal Hocko
2020-01-17 13:08   ` David Hildenbrand
2020-01-17 14:52     ` Michal Hocko
2020-01-17 14:58       ` David Hildenbrand
2020-01-17 15:29         ` Michal Hocko
2020-01-17 15:54           ` Dan Williams
2020-01-17 16:10             ` David Hildenbrand
2020-01-17 16:57               ` Dan Williams
2020-01-20  7:48                 ` Michal Hocko
2020-01-20  9:14                   ` David Hildenbrand
2020-01-20  9:20                     ` David Hildenbrand
2020-01-21 12:07                     ` Michal Hocko
2020-01-22 10:39                       ` David Hildenbrand
2020-01-22 10:42                         ` Michal Hocko
2020-01-22 10:54                           ` David Hildenbrand [this message]
2020-01-22 11:58                             ` David Hildenbrand
2020-01-22 16:46                               ` Michal Hocko
2020-01-22 18:15                                 ` David Hildenbrand
2020-01-22 18:38                                   ` Michal Hocko
2020-01-22 18:46                                     ` David Hildenbrand
2020-01-22 19:09                                       ` Michal Hocko
2020-01-22 20:51                                         ` Dan Williams
2020-01-22 19:01                                   ` Michal Hocko

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=98b6c208-b4dd-9052-43f6-543068c649cc@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=allison@lohutok.net \
    --cc=anshuman.khandual@arm.com \
    --cc=benh@kernel.crashing.org \
    --cc=dan.j.williams@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=lantianyu1986@gmail.com \
    --cc=leonardo@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mhocko@kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=nathanl@linux.ibm.com \
    --cc=nfont@linux.vnet.ibm.com \
    --cc=paulus@samba.org \
    --cc=rafael@kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=tglx@linutronix.de \
    /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;
as well as URLs for NNTP newsgroup(s).