From: Sumanth Korikkar <sumanthk@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>
Cc: linux-mm <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Oscar Salvador <osalvador@suse.de>,
Michal Hocko <mhocko@suse.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Gerald Schaefer <gerald.schaefer@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
linux-s390 <linux-s390@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 4/5] s390/mm: implement MEM_PREPARE_ONLINE/MEM_FINISH_OFFLINE notifiers
Date: Mon, 27 Nov 2023 17:12:21 +0100 [thread overview]
Message-ID: <ZWS/5ZzhGzt6ykfq@li-2b55cdcc-350b-11b2-a85c-a78bff51fc11.ibm.com> (raw)
In-Reply-To: <abbe4d53-e944-46cc-90fc-a0a65e50b2fe@redhat.com>
On Mon, Nov 27, 2023 at 04:11:05PM +0100, David Hildenbrand wrote:
> > diff --git a/drivers/s390/char/sclp_cmd.c b/drivers/s390/char/sclp_cmd.c
> > index 355e63e44e95..30b829e4c052 100644
> > --- a/drivers/s390/char/sclp_cmd.c
> > +++ b/drivers/s390/char/sclp_cmd.c
> > @@ -18,6 +18,7 @@
> > #include <linux/mm.h>
> > #include <linux/mmzone.h>
> > #include <linux/memory.h>
> > +#include <linux/memory_hotplug.h>
> > #include <linux/module.h>
> > #include <asm/ctlreg.h>
> > #include <asm/chpid.h>
> > @@ -26,6 +27,7 @@
> > #include <asm/sclp.h>
> > #include <asm/numa.h>
> > #include <asm/facility.h>
> > +#include <asm/page-states.h>
> > #include "sclp.h"
> > @@ -319,6 +321,7 @@ static bool contains_standby_increment(unsigned long start, unsigned long end)
> > static int sclp_mem_notifier(struct notifier_block *nb,
> > unsigned long action, void *data)
> > {
> > + struct memory_block *memory_block;
> > unsigned long start, size;
> > struct memory_notify *arg;
> > unsigned char id;
> > @@ -340,18 +343,29 @@ static int sclp_mem_notifier(struct notifier_block *nb,
> > if (contains_standby_increment(start, start + size))
> > rc = -EPERM;
> > break;
> > - case MEM_GOING_ONLINE:
> > + case MEM_PREPARE_ONLINE:
> > + memory_block = find_memory_block(pfn_to_section_nr(arg->start_pfn));
> > + if (!memory_block) {
> > + rc = -EINVAL;
> > + goto out;
> > + }
> > rc = sclp_mem_change_state(start, size, 1);
> > + if (rc || !memory_block->altmap)
> > + goto out;
> > + /*
> > + * Set CMMA state to nodat here, since the struct page memory
> > + * at the beginning of the memory block will not go through the
> > + * buddy allocator later.
> > + */
> > + __arch_set_page_nodat((void *)__va(start), memory_block->altmap->free);
>
> Looking up the memory block and grabbing the altmap from there is a bit
> unfortunate.
>
> Why can't we do that when adding the altmap? Will the hypervisor scream at
> us?
>
calling __arch_set_page_nodat() before making memory block accessible
will lead to crash. Hence, we think this is the only safe location to
place it.
> ... would we want to communicate any altmap start+size via the memory
> notifier instead?
Passing start, size of memory range via memory notifier looks correct
approach to me, as we try to make the specified range accessible.
If we want to pass altmap size (nr_vmemmap_pages), then we might need a
new field in struct memory_notify, which would prevent access of
memory_block->altmap->free in the notifier.
Do you want to take this approach instead?
If yes, Then I could add a new field nr_vmemmap_pages in struct
memory_notify and place it in PATCH : introduce
MEM_PREPARE_ONLINE/MEM_FINISH_OFFLINE notifiers.
Thanks
next prev parent reply other threads:[~2023-11-27 16:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-27 8:20 [PATCH v3 0/5] implement "memmap on memory" feature on s390 Sumanth Korikkar
2023-11-27 8:20 ` [PATCH v3 1/5] mm/memory_hotplug: introduce MEM_PREPARE_ONLINE/MEM_FINISH_OFFLINE notifiers Sumanth Korikkar
2023-11-27 15:16 ` David Hildenbrand
2023-11-28 7:54 ` Sumanth Korikkar
2023-11-27 15:50 ` David Hildenbrand
2023-11-27 8:20 ` [PATCH v3 2/5] s390/mm: allocate vmemmap pages from self-contained memory range Sumanth Korikkar
2023-11-27 8:20 ` [PATCH v3 3/5] s390/sclp: remove unhandled memory notifier type Sumanth Korikkar
2023-11-27 15:02 ` David Hildenbrand
[not found] ` <20231127082023.2079810-5-sumanthk@linux.ibm.com>
2023-11-27 15:11 ` [PATCH v3 4/5] s390/mm: implement MEM_PREPARE_ONLINE/MEM_FINISH_OFFLINE notifiers David Hildenbrand
2023-11-27 16:12 ` Sumanth Korikkar [this message]
2023-11-27 16:58 ` 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=ZWS/5ZzhGzt6ykfq@li-2b55cdcc-350b-11b2-a85c-a78bff51fc11.ibm.com \
--to=sumanthk@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=anshuman.khandual@arm.com \
--cc=david@redhat.com \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=mhocko@suse.com \
--cc=osalvador@suse.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