From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>, Vlastimil Babka <vbabka@suse.cz>,
Andrea Arcangeli <aarcange@redhat.com>,
Jerome Glisse <jglisse@redhat.com>,
Reza Arbab <arbab@linux.vnet.ibm.com>,
Yasuaki Ishimatsu <yasu.isimatu@gmail.com>,
qiuxishi@huawei.com, Kani Toshimitsu <toshi.kani@hpe.com>,
slaoub@gmail.com, Joonsoo Kim <js1304@gmail.com>,
Andi Kleen <ak@linux.intel.com>,
Daniel Kiper <daniel.kiper@oracle.com>,
Igor Mammedov <imammedo@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Dan Williams <dan.j.williams@intel.com>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Paul Mackerras <paulus@samba.org>,
Thomas Gleixner <tglx@linutronix.de>,
gerald.schaefer@de.ibm.com,
Martin Schwidefsky <mschwide@de.ibm.com>
Subject: Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap
Date: Wed, 26 Jul 2017 19:20:39 +0200 [thread overview]
Message-ID: <20170726192039.48b81161@thinkpad> (raw)
In-Reply-To: <20170726123040.GO2981@dhcp22.suse.cz>
On Wed, 26 Jul 2017 14:30:41 +0200
Michal Hocko <mhocko@kernel.org> wrote:
> On Wed 26-07-17 13:45:39, Heiko Carstens wrote:
> [...]
> > In general I do like your idea, however if I understand your patches
> > correctly we might have an ordering problem on s390: it is not possible to
> > access hot-added memory on s390 before it is online (MEM_GOING_ONLINE
> > succeeded).
>
> Could you point me to the code please? I cannot seem to find the
> notifier which implements that.
It is in drivers/s390/char/sclp_cmd.c: sclp_mem_notifier().
>
> > On MEM_GOING_ONLINE we ask the hypervisor to back the potential available
> > hot-added memory region with physical pages. Accessing those ranges before
> > that will result in an exception.
>
> Can we make the range which backs the memmap range available? E.g from
> s390 specific __vmemmap_populate path?
No, only the complete range of a storage increment can be made available.
The size of those increments may vary between z/VM and LPAR, but at least
with LPAR it will always be minimum 256 MB, IIRC.
>
> > However with your approach the memory is still allocated when add_memory()
> > is being called, correct? That wouldn't be a change to the current
> > behaviour; except for the ordering problem outlined above.
>
> Could you be more specific please? I do not change when the memmap is
> allocated.
I guess this is about the difference between s390 and others, wrt when
we call add_memory(). It is also in drivers/s390/char/sclp_cmd.c, early
during memory detection, as opposed to other archs, where I guess this
could be triggered by an ACPI event during runtime, at least for newly
added and to-be-onlined memory.
This probably means that any approach that tries to allocate memmap
memory during add_memory(), out of the "to-be-onlined but still offline"
memory, will be difficult for s390, because we call add_memory() only once
during memory detection for the complete range of (hypervisor) defined
online and offline memory. The offline parts are then made available in
the MEM_GOING_ONLINE notifier called from online_pages(). Only after
this point the memory would then be available to allocate a memmap in it.
Nevertheless, we have great interest in such a "allocate memmap from
the added memory range" solution. I guess we would need some way to
separate the memmap allocation from add_memory(), which sounds odd,
or provide some way to have add_memory() only allocate a memmap for
online memory, and a mechanism to add the memmaps for offline memory
blocks later when they are being set online.
Regards,
Gerald
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>, Vlastimil Babka <vbabka@suse.cz>,
Andrea Arcangeli <aarcange@redhat.com>,
Jerome Glisse <jglisse@redhat.com>,
Reza Arbab <arbab@linux.vnet.ibm.com>,
Yasuaki Ishimatsu <yasu.isimatu@gmail.com>,
qiuxishi@huawei.com, Kani Toshimitsu <toshi.kani@hpe.com>,
slaoub@gmail.com, Joonsoo Kim <js1304@gmail.com>,
Andi Kleen <ak@linux.intel.com>,
Daniel Kiper <daniel.kiper@oracle.com>,
Igor Mammedov <imammedo@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Dan Williams <dan.j.williams@intel.com>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Paul Mackerras <paulus@samba.org>,
Thomas Gleixner <tglx@linutronix.de>,
gerald.schaefer@de.ibm.com,
Martin Schwidefsky <mschwide@de.ibm.com>
Subject: Re: [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap
Date: Wed, 26 Jul 2017 19:20:39 +0200 [thread overview]
Message-ID: <20170726192039.48b81161@thinkpad> (raw)
In-Reply-To: <20170726123040.GO2981@dhcp22.suse.cz>
On Wed, 26 Jul 2017 14:30:41 +0200
Michal Hocko <mhocko@kernel.org> wrote:
> On Wed 26-07-17 13:45:39, Heiko Carstens wrote:
> [...]
> > In general I do like your idea, however if I understand your patches
> > correctly we might have an ordering problem on s390: it is not possible to
> > access hot-added memory on s390 before it is online (MEM_GOING_ONLINE
> > succeeded).
>
> Could you point me to the code please? I cannot seem to find the
> notifier which implements that.
It is in drivers/s390/char/sclp_cmd.c: sclp_mem_notifier().
>
> > On MEM_GOING_ONLINE we ask the hypervisor to back the potential available
> > hot-added memory region with physical pages. Accessing those ranges before
> > that will result in an exception.
>
> Can we make the range which backs the memmap range available? E.g from
> s390 specific __vmemmap_populate path?
No, only the complete range of a storage increment can be made available.
The size of those increments may vary between z/VM and LPAR, but at least
with LPAR it will always be minimum 256 MB, IIRC.
>
> > However with your approach the memory is still allocated when add_memory()
> > is being called, correct? That wouldn't be a change to the current
> > behaviour; except for the ordering problem outlined above.
>
> Could you be more specific please? I do not change when the memmap is
> allocated.
I guess this is about the difference between s390 and others, wrt when
we call add_memory(). It is also in drivers/s390/char/sclp_cmd.c, early
during memory detection, as opposed to other archs, where I guess this
could be triggered by an ACPI event during runtime, at least for newly
added and to-be-onlined memory.
This probably means that any approach that tries to allocate memmap
memory during add_memory(), out of the "to-be-onlined but still offline"
memory, will be difficult for s390, because we call add_memory() only once
during memory detection for the complete range of (hypervisor) defined
online and offline memory. The offline parts are then made available in
the MEM_GOING_ONLINE notifier called from online_pages(). Only after
this point the memory would then be available to allocate a memmap in it.
Nevertheless, we have great interest in such a "allocate memmap from
the added memory range" solution. I guess we would need some way to
separate the memmap allocation from add_memory(), which sounds odd,
or provide some way to have add_memory() only allocate a memmap for
online memory, and a mechanism to add the memmaps for offline memory
blocks later when they are being set online.
Regards,
Gerald
next prev parent reply other threads:[~2017-07-26 17:20 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-26 8:33 [RFC PATCH 0/5] mm, memory_hotplug: allocate memmap from hotadded memory Michal Hocko
2017-07-26 8:33 ` Michal Hocko
2017-07-26 8:33 ` [RFC PATCH 1/5] mm, memory_hotplug: cleanup memory offline path Michal Hocko
2017-07-26 8:33 ` Michal Hocko
2017-07-26 8:33 ` [RFC PATCH 2/5] mm, arch: unify vmemmap_populate altmap handling Michal Hocko
2017-07-26 8:33 ` Michal Hocko
2017-07-31 12:40 ` Gerald Schaefer
2017-07-31 12:40 ` Gerald Schaefer
2017-07-31 12:55 ` Michal Hocko
2017-07-31 12:55 ` Michal Hocko
2017-07-31 14:27 ` Gerald Schaefer
2017-07-31 14:27 ` Gerald Schaefer
2017-07-31 14:36 ` Michal Hocko
2017-07-31 14:36 ` Michal Hocko
2017-07-26 8:33 ` [RFC PATCH 3/5] mm, memory_hotplug: allocate memmap from the added memory range for sparse-vmemmap Michal Hocko
2017-07-26 8:33 ` Michal Hocko
2017-07-26 11:45 ` Heiko Carstens
2017-07-26 11:45 ` Heiko Carstens
2017-07-26 11:49 ` Heiko Carstens
2017-07-26 11:49 ` Heiko Carstens
2017-07-26 12:30 ` Michal Hocko
2017-07-26 12:30 ` Michal Hocko
2017-07-26 17:20 ` Gerald Schaefer [this message]
2017-07-26 17:20 ` Gerald Schaefer
2017-07-28 11:26 ` Michal Hocko
2017-07-28 11:26 ` Michal Hocko
2017-07-28 17:47 ` Michal Hocko
2017-07-28 17:47 ` Michal Hocko
2017-07-26 8:33 ` [RFC PATCH 4/5] mm, sparse: complain about implicit altmap usage in vmemmap_populate Michal Hocko
2017-07-26 8:33 ` Michal Hocko
2017-07-26 8:33 ` [RFC PATCH 5/5] mm, sparse: rename kmalloc_section_memmap, __kfree_section_memmap Michal Hocko
2017-07-26 8:33 ` Michal Hocko
2017-07-26 11:39 ` [RFC PATCH 0/5] mm, memory_hotplug: allocate memmap from hotadded memory Michal Hocko
2017-07-26 11:39 ` Michal Hocko
2017-07-26 21:06 ` Jerome Glisse
2017-07-26 21:06 ` Jerome Glisse
2017-07-27 6:56 ` Michal Hocko
2017-07-27 6:56 ` Michal Hocko
2017-07-28 12:19 ` Michal Hocko
2017-07-28 12:19 ` Michal Hocko
2017-07-31 12:35 ` Gerald Schaefer
2017-07-31 12:35 ` Gerald Schaefer
2017-07-31 12:53 ` Michal Hocko
2017-07-31 12:53 ` Michal Hocko
2017-07-31 15:04 ` Gerald Schaefer
2017-07-31 15:04 ` Gerald Schaefer
2017-07-31 15:53 ` Michal Hocko
2017-07-31 15:53 ` Michal Hocko
2017-07-31 17:58 ` Gerald Schaefer
2017-07-31 17:58 ` Gerald Schaefer
2017-08-01 11:30 ` Igor Mammedov
2017-08-01 11:30 ` Igor Mammedov
2017-08-01 12:27 ` Michal Hocko
2017-08-01 12:27 ` Michal Hocko
2017-07-28 12:01 ` Michal Hocko
2017-07-28 12: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=20170726192039.48b81161@thinkpad \
--to=gerald.schaefer@de.ibm.com \
--cc=aarcange@redhat.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=arbab@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=dan.j.williams@intel.com \
--cc=daniel.kiper@oracle.com \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=imammedo@redhat.com \
--cc=jglisse@redhat.com \
--cc=js1304@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=mschwide@de.ibm.com \
--cc=paulus@samba.org \
--cc=qiuxishi@huawei.com \
--cc=slaoub@gmail.com \
--cc=tglx@linutronix.de \
--cc=toshi.kani@hpe.com \
--cc=vbabka@suse.cz \
--cc=vkuznets@redhat.com \
--cc=yasu.isimatu@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.