From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: 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>,
Catalin Marinas <catalin.marinas@arm.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Paul Mackerras <paulus@samba.org>,
Thomas Gleixner <tglx@linutronix.de>,
Tony Luck <tony.luck@intel.com>,
Will Deacon <will.deacon@arm.com>,
gerald.schaefer@de.ibm.com
Subject: Re: [RFC PATCH 2/5] mm, arch: unify vmemmap_populate altmap handling
Date: Mon, 31 Jul 2017 16:27:46 +0200 [thread overview]
Message-ID: <20170731162746.60b8d98e@thinkpad> (raw)
In-Reply-To: <20170731125555.GB4829@dhcp22.suse.cz>
On Mon, 31 Jul 2017 14:55:56 +0200
Michal Hocko <mhocko@kernel.org> wrote:
> On Mon 31-07-17 14:40:53, Gerald Schaefer wrote:
> [...]
> > > @@ -247,12 +248,12 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node)
> > > * use large frames even if they are only partially
> > > * used.
> > > * Otherwise we would have also page tables since
> > > - * vmemmap_populate gets called for each section
> > > + * __vmemmap_populate gets called for each section
> > > * separately. */
> > > if (MACHINE_HAS_EDAT1) {
> > > void *new_page;
> > >
> > > - new_page = vmemmap_alloc_block(PMD_SIZE, node);
> > > + new_page = __vmemmap_alloc_block_buf(PMD_SIZE, node, altmap);
> > > if (!new_page)
> > > goto out;
> > > pmd_val(*pm_dir) = __pa(new_page) | sgt_prot;
> >
> > There is another call to vmemmap_alloc_block() in this function, a couple
> > of lines below, this should also be replaced by __vmemmap_alloc_block_buf().
>
> I've noticed that one but in general I have only transformed PMD
> mappings because we shouldn't even get to pte level if the forme works
> AFAICS. Memory sections should be always 2MB aligned unless I am missing
> something. Or is this not true?
vmemmap_populate() on s390 will only stop at pmd level if we have HW
support for large pages (MACHINE_HAS_EDAT1). In that case we will allocate
a PMD_SIZE block with vmemmap_alloc_block() and map it on pmd level as
a large page.
Without HW large page support, we will continue to allocate a pte page,
populate the pmd entry with that, and fall through to the pte_none()
check below, with its PAGE_SIZE vmemmap_alloc_block() allocation. In this
case we should use the __vmemmap_alloc_block_buf().
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: 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>,
Catalin Marinas <catalin.marinas@arm.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Paul Mackerras <paulus@samba.org>,
Thomas Gleixner <tglx@linutronix.de>,
Tony Luck <tony.luck@intel.com>,
Will Deacon <will.deacon@arm.com>,
gerald.schaefer@de.ibm.com
Subject: Re: [RFC PATCH 2/5] mm, arch: unify vmemmap_populate altmap handling
Date: Mon, 31 Jul 2017 16:27:46 +0200 [thread overview]
Message-ID: <20170731162746.60b8d98e@thinkpad> (raw)
In-Reply-To: <20170731125555.GB4829@dhcp22.suse.cz>
On Mon, 31 Jul 2017 14:55:56 +0200
Michal Hocko <mhocko@kernel.org> wrote:
> On Mon 31-07-17 14:40:53, Gerald Schaefer wrote:
> [...]
> > > @@ -247,12 +248,12 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node)
> > > * use large frames even if they are only partially
> > > * used.
> > > * Otherwise we would have also page tables since
> > > - * vmemmap_populate gets called for each section
> > > + * __vmemmap_populate gets called for each section
> > > * separately. */
> > > if (MACHINE_HAS_EDAT1) {
> > > void *new_page;
> > >
> > > - new_page = vmemmap_alloc_block(PMD_SIZE, node);
> > > + new_page = __vmemmap_alloc_block_buf(PMD_SIZE, node, altmap);
> > > if (!new_page)
> > > goto out;
> > > pmd_val(*pm_dir) = __pa(new_page) | sgt_prot;
> >
> > There is another call to vmemmap_alloc_block() in this function, a couple
> > of lines below, this should also be replaced by __vmemmap_alloc_block_buf().
>
> I've noticed that one but in general I have only transformed PMD
> mappings because we shouldn't even get to pte level if the forme works
> AFAICS. Memory sections should be always 2MB aligned unless I am missing
> something. Or is this not true?
vmemmap_populate() on s390 will only stop at pmd level if we have HW
support for large pages (MACHINE_HAS_EDAT1). In that case we will allocate
a PMD_SIZE block with vmemmap_alloc_block() and map it on pmd level as
a large page.
Without HW large page support, we will continue to allocate a pte page,
populate the pmd entry with that, and fall through to the pte_none()
check below, with its PAGE_SIZE vmemmap_alloc_block() allocation. In this
case we should use the __vmemmap_alloc_block_buf().
Regards,
Gerald
next prev parent reply other threads:[~2017-07-31 14:28 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 [this message]
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
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=20170731162746.60b8d98e@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=catalin.marinas@arm.com \
--cc=daniel.kiper@oracle.com \
--cc=fenghua.yu@intel.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=paulus@samba.org \
--cc=qiuxishi@huawei.com \
--cc=schwidefsky@de.ibm.com \
--cc=slaoub@gmail.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=toshi.kani@hpe.com \
--cc=vbabka@suse.cz \
--cc=vkuznets@redhat.com \
--cc=will.deacon@arm.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.