From: David Hildenbrand <david@redhat.com>
To: Dave Hansen <dave.hansen@linux.intel.com>, linux-mm@kvack.org
Cc: "Kate Stewart" <kstewart@linuxfoundation.org>,
"Rich Felker" <dalias@libc.org>,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
"Peter Zijlstra" <peterz@infradead.org>,
"Heiko Carstens" <heiko.carstens@de.ibm.com>,
"Pavel Tatashin" <pavel.tatashin@microsoft.com>,
"Michal Hocko" <mhocko@suse.com>,
"Paul Mackerras" <paulus@samba.org>,
"H. Peter Anvin" <hpa@zytor.com>,
"Rashmica Gupta" <rashmica.g@gmail.com>,
"K. Y. Srinivasan" <kys@microsoft.com>,
"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
linux-s390@vger.kernel.org, "Michael Neuling" <mikey@neuling.org>,
"Stephen Hemminger" <sthemmin@microsoft.com>,
"Yoshinori Sato" <ysato@users.sourceforge.jp>,
linux-acpi@vger.kernel.org, "Ingo Molnar" <mingo@redhat.com>,
xen-devel@lists.xenproject.org, "Rob Herring" <robh@kernel.org>,
"Len Brown" <lenb@kernel.org>,
"Fenghua Yu" <fenghua.yu@intel.com>,
"Stephen Rothwell" <sfr@canb.auug.org.au>,
"mike.travis@hpe.com" <mike.travis@hpe.com>,
"Haiyang Zhang" <haiyangz@microsoft.com>,
"Dan Williams" <dan.j.williams@intel.com>,
"Jonathan Neuschäfer" <j.neuschaefer@gmx.net>,
"Nicholas Piggin" <npiggin@gmail.com>,
"Joe Perches" <joe@perches.com>,
"Jérôme Glisse" <jglisse@redhat.com>,
"Mike Rapoport" <rppt@linux.vnet.ibm.com>,
"Borislav Petkov" <bp@alien8.de>,
"Andy Lutomirski" <luto@kernel.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Joonsoo Kim" <iamjoonsoo.kim@lge.com>,
"Oscar Salvador" <osalvador@suse.de>,
"Juergen Gross" <jgross@suse.com>,
"Tony Luck" <tony.luck@intel.com>,
"Mathieu Malaterre" <malat@debian.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-kernel@vger.kernel.org,
"Mauricio Faria de Oliveira" <mauricfo@linux.vnet.ibm.com>,
"Philippe Ombredanne" <pombredanne@nexb.com>,
"Martin Schwidefsky" <schwidefsky@de.ibm.com>,
devel@linuxdriverproject.org,
"Andrew Morton" <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types
Date: Thu, 4 Oct 2018 09:48:32 +0200 [thread overview]
Message-ID: <746a61c2-ebc7-abff-3bcd-7e307ef449bd@redhat.com> (raw)
In-Reply-To: <05493150-5e4e-30bd-f772-0c6d88240030@linux.intel.com>
On 01/10/2018 18:24, Dave Hansen wrote:
>> How should a policy in user space look like when new memory gets added
>> - on s390x? Not onlining paravirtualized memory is very wrong.
>
> Because we're going to balloon it away in a moment anyway?
No, rether somebody wanted this VM to have more memory, so it should use
it - basically what HyperV or XEN also do. (in contrast to the concept
of standby memory on s390).
> > We have auto-onlining. Why isn't that being used on s390?
Do you mean the sys parameter? How would that help?
>
>
>> So the type of memory is very important here to have in user space.
>> Relying on checks like "isS390()", "isKVMGuest()" or "isHyperVGuest()"
>> to decide whether to online memory and how to online memory is wrong.
>> Only some specific memory types (which I call "normal") are to be
>> handled by user space.
>>
>> For the other ones, we exactly know what to do:
>> - standby? don't online
>
> I think you're horribly conflating the software desire for what the stae
> should be and the hardware itself.
Agreed, user space should be able to configure it.
>
>>> As for the OOM issues, that sounds like something we need to fix by
>>> refusing to do (or delaying) hot-add operations once we consume too much
>>> ZONE_NORMAL from memmap[]s rather than trying to indirectly tell
>>> userspace to hurry thing along.
>>
>> That is a moving target and doing that automatically is basically
>> impossible.
>
> Nah. We know how much metadata we've allocated. We know how much
> ZONE_NORMAL we are eating. We can *easily* add something to
> add_memory() that just sleeps until the ratio is not out-of-whack.
>
>> You can add a lot of memory to the movable zone and
>> everything is fine. Suddenly a lot of processes are started - boom.
>> MOVABLE should only every be used if you expect an unplug. And for
>> paravirtualized devices, a "typical" unplug does not exist.
>
> No, it's more complicated than that. People use MOVABLE, for instance,
> to allow more consistent huge page allocations. It's certainly not just
> hot-remove.
>
As noted in the other thread, that's a good point. We have to allow to
make a decision in user space.
I agree to your initial proposal to distinguish "standby" from
"auto-online". It would allow to have sane defaults in user space.
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2018-10-04 7:50 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-28 15:03 [PATCH RFC] mm/memory_hotplug: Introduce memory block types David Hildenbrand
2018-09-28 17:02 ` Dave Hansen
2018-10-01 9:13 ` David Hildenbrand
2018-10-01 16:24 ` Dave Hansen
2018-10-04 7:48 ` David Hildenbrand [this message]
2018-10-01 8:40 ` Michal Hocko
2018-10-01 9:34 ` David Hildenbrand
2018-10-02 13:47 ` Michal Hocko
2018-10-02 15:25 ` David Hildenbrand
2018-10-03 13:38 ` Vitaly Kuznetsov
2018-10-03 13:44 ` Michal Hocko
2018-10-03 13:52 ` Vitaly Kuznetsov
2018-10-03 14:07 ` Dave Hansen
2018-10-03 14:34 ` Vitaly Kuznetsov
2018-10-03 17:14 ` David Hildenbrand
2018-10-04 6:19 ` Michal Hocko
2018-10-04 8:13 ` David Hildenbrand
2018-10-04 15:28 ` Michal Suchánek
2018-10-04 15:45 ` David Hildenbrand
2018-10-04 17:50 ` Michal Suchánek
2018-10-05 7:37 ` David Hildenbrand
2018-10-03 14:24 ` Michal Hocko
2018-10-03 17:06 ` David Hildenbrand
2018-10-04 8:12 ` David Hildenbrand
2018-10-03 13:54 ` Michal Hocko
2018-10-03 17:00 ` David Hildenbrand
2018-10-04 6:28 ` Michal Hocko
2018-10-04 7:40 ` David Hildenbrand
2018-11-23 11:13 ` David Hildenbrand
2018-11-23 18:06 ` Michal Suchánek
2018-11-26 12:30 ` David Hildenbrand
2018-11-26 13:33 ` David Hildenbrand
2018-11-26 14:20 ` Michal Suchánek
2018-11-26 15:59 ` David Hildenbrand
2018-11-27 16:32 ` Michal Suchánek
2018-11-27 16:47 ` David Hildenbrand
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=746a61c2-ebc7-abff-3bcd-7e307ef449bd@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=dalias@libc.org \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=devel@linuxdriverproject.org \
--cc=fenghua.yu@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=haiyangz@microsoft.com \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=j.neuschaefer@gmx.net \
--cc=jglisse@redhat.com \
--cc=jgross@suse.com \
--cc=joe@perches.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kstewart@linuxfoundation.org \
--cc=kys@microsoft.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=luto@kernel.org \
--cc=malat@debian.org \
--cc=mauricfo@linux.vnet.ibm.com \
--cc=mhocko@suse.com \
--cc=mike.travis@hpe.com \
--cc=mikey@neuling.org \
--cc=mingo@redhat.com \
--cc=npiggin@gmail.com \
--cc=osalvador@suse.de \
--cc=paulus@samba.org \
--cc=pavel.tatashin@microsoft.com \
--cc=peterz@infradead.org \
--cc=pombredanne@nexb.com \
--cc=rashmica.g@gmail.com \
--cc=rjw@rjwysocki.net \
--cc=robh@kernel.org \
--cc=rppt@linux.vnet.ibm.com \
--cc=schwidefsky@de.ibm.com \
--cc=sfr@canb.auug.org.au \
--cc=sthemmin@microsoft.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=xen-devel@lists.xenproject.org \
--cc=ysato@users.sourceforge.jp \
/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).