From: Catalin Marinas <catalin.marinas@arm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: linux-mm@kvack.org, Will Deacon <will@kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Andrew Morton <akpm@linux-foundation.org>,
x86@kernel.org, linux-arm-kernel@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V3 (RESEND) 2/3] mm/sparsemem: Enable vmem_altmap support in vmemmap_alloc_block_buf()
Date: Thu, 2 Jul 2020 15:07:52 +0100 [thread overview]
Message-ID: <20200702140752.GF22241@gaia> (raw)
In-Reply-To: <1592442930-9380-3-git-send-email-anshuman.khandual@arm.com>
On Thu, Jun 18, 2020 at 06:45:29AM +0530, Anshuman Khandual wrote:
> There are many instances where vmemap allocation is often switched between
> regular memory and device memory just based on whether altmap is available
> or not. vmemmap_alloc_block_buf() is used in various platforms to allocate
> vmemmap mappings. Lets also enable it to handle altmap based device memory
> allocation along with existing regular memory allocations. This will help
> in avoiding the altmap based allocation switch in many places.
>
> While here also implement a regular memory allocation fallback mechanism
> when the first preferred device memory allocation fails. This will ensure
> preserving the existing semantics on powerpc platform. To summarize there
> are three different methods to call vmemmap_alloc_block_buf().
>
> (., NULL, false) /* Allocate from system RAM */
> (., altmap, false) /* Allocate from altmap without any fallback */
> (., altmap, true) /* Allocate from altmap with fallback (system RAM) */
[...]
> diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
> index bc73abf0bc25..01e25b56eccb 100644
> --- a/arch/powerpc/mm/init_64.c
> +++ b/arch/powerpc/mm/init_64.c
> @@ -225,12 +225,12 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
> * fall back to system memory if the altmap allocation fail.
> */
> if (altmap && !altmap_cross_boundary(altmap, start, page_size)) {
> - p = altmap_alloc_block_buf(page_size, altmap);
> - if (!p)
> - pr_debug("altmap block allocation failed, falling back to system memory");
> + p = vmemmap_alloc_block_buf(page_size, node,
> + altmap, true);
> + } else {
> + p = vmemmap_alloc_block_buf(page_size, node,
> + NULL, false);
> }
> - if (!p)
> - p = vmemmap_alloc_block_buf(page_size, node);
> if (!p)
> return -ENOMEM;
Is the fallback argument actually necessary. It may be cleaner to just
leave the code as is with the choice between altmap and NULL. If an arch
needs a fallback (only powerpc), they have the fallback in place
already. I don't see the powerpc code any better after this change.
I'm fine with the altmap argument though.
--
Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Ingo Molnar <mingo@redhat.com>,
Paul Mackerras <paulus@samba.org>,
Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
Will Deacon <will@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH V3 (RESEND) 2/3] mm/sparsemem: Enable vmem_altmap support in vmemmap_alloc_block_buf()
Date: Thu, 2 Jul 2020 15:07:52 +0100 [thread overview]
Message-ID: <20200702140752.GF22241@gaia> (raw)
In-Reply-To: <1592442930-9380-3-git-send-email-anshuman.khandual@arm.com>
On Thu, Jun 18, 2020 at 06:45:29AM +0530, Anshuman Khandual wrote:
> There are many instances where vmemap allocation is often switched between
> regular memory and device memory just based on whether altmap is available
> or not. vmemmap_alloc_block_buf() is used in various platforms to allocate
> vmemmap mappings. Lets also enable it to handle altmap based device memory
> allocation along with existing regular memory allocations. This will help
> in avoiding the altmap based allocation switch in many places.
>
> While here also implement a regular memory allocation fallback mechanism
> when the first preferred device memory allocation fails. This will ensure
> preserving the existing semantics on powerpc platform. To summarize there
> are three different methods to call vmemmap_alloc_block_buf().
>
> (., NULL, false) /* Allocate from system RAM */
> (., altmap, false) /* Allocate from altmap without any fallback */
> (., altmap, true) /* Allocate from altmap with fallback (system RAM) */
[...]
> diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
> index bc73abf0bc25..01e25b56eccb 100644
> --- a/arch/powerpc/mm/init_64.c
> +++ b/arch/powerpc/mm/init_64.c
> @@ -225,12 +225,12 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
> * fall back to system memory if the altmap allocation fail.
> */
> if (altmap && !altmap_cross_boundary(altmap, start, page_size)) {
> - p = altmap_alloc_block_buf(page_size, altmap);
> - if (!p)
> - pr_debug("altmap block allocation failed, falling back to system memory");
> + p = vmemmap_alloc_block_buf(page_size, node,
> + altmap, true);
> + } else {
> + p = vmemmap_alloc_block_buf(page_size, node,
> + NULL, false);
> }
> - if (!p)
> - p = vmemmap_alloc_block_buf(page_size, node);
> if (!p)
> return -ENOMEM;
Is the fallback argument actually necessary. It may be cleaner to just
leave the code as is with the choice between altmap and NULL. If an arch
needs a fallback (only powerpc), they have the fallback in place
already. I don't see the powerpc code any better after this change.
I'm fine with the altmap argument though.
--
Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Dave Hansen <dave.hansen@linux.intel.com>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Ingo Molnar <mingo@redhat.com>,
Paul Mackerras <paulus@samba.org>,
Andy Lutomirski <luto@kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
Will Deacon <will@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH V3 (RESEND) 2/3] mm/sparsemem: Enable vmem_altmap support in vmemmap_alloc_block_buf()
Date: Thu, 2 Jul 2020 15:07:52 +0100 [thread overview]
Message-ID: <20200702140752.GF22241@gaia> (raw)
In-Reply-To: <1592442930-9380-3-git-send-email-anshuman.khandual@arm.com>
On Thu, Jun 18, 2020 at 06:45:29AM +0530, Anshuman Khandual wrote:
> There are many instances where vmemap allocation is often switched between
> regular memory and device memory just based on whether altmap is available
> or not. vmemmap_alloc_block_buf() is used in various platforms to allocate
> vmemmap mappings. Lets also enable it to handle altmap based device memory
> allocation along with existing regular memory allocations. This will help
> in avoiding the altmap based allocation switch in many places.
>
> While here also implement a regular memory allocation fallback mechanism
> when the first preferred device memory allocation fails. This will ensure
> preserving the existing semantics on powerpc platform. To summarize there
> are three different methods to call vmemmap_alloc_block_buf().
>
> (., NULL, false) /* Allocate from system RAM */
> (., altmap, false) /* Allocate from altmap without any fallback */
> (., altmap, true) /* Allocate from altmap with fallback (system RAM) */
[...]
> diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
> index bc73abf0bc25..01e25b56eccb 100644
> --- a/arch/powerpc/mm/init_64.c
> +++ b/arch/powerpc/mm/init_64.c
> @@ -225,12 +225,12 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
> * fall back to system memory if the altmap allocation fail.
> */
> if (altmap && !altmap_cross_boundary(altmap, start, page_size)) {
> - p = altmap_alloc_block_buf(page_size, altmap);
> - if (!p)
> - pr_debug("altmap block allocation failed, falling back to system memory");
> + p = vmemmap_alloc_block_buf(page_size, node,
> + altmap, true);
> + } else {
> + p = vmemmap_alloc_block_buf(page_size, node,
> + NULL, false);
> }
> - if (!p)
> - p = vmemmap_alloc_block_buf(page_size, node);
> if (!p)
> return -ENOMEM;
Is the fallback argument actually necessary. It may be cleaner to just
leave the code as is with the choice between altmap and NULL. If an arch
needs a fallback (only powerpc), they have the fallback in place
already. I don't see the powerpc code any better after this change.
I'm fine with the altmap argument though.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-07-02 14:07 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-18 1:15 [PATCH V3 (RESEND) 0/3] arm64: Enable vmemmap mapping from device memory Anshuman Khandual
2020-06-18 1:27 ` Anshuman Khandual
2020-06-18 1:15 ` Anshuman Khandual
2020-06-18 1:15 ` Anshuman Khandual
2020-06-18 1:15 ` Anshuman Khandual
2020-06-18 1:15 ` [PATCH V3 (RESEND) 1/3] mm/sparsemem: Enable vmem_altmap support in vmemmap_populate_basepages() Anshuman Khandual
2020-06-18 1:27 ` Anshuman Khandual
2020-06-18 1:15 ` Anshuman Khandual
2020-06-18 1:15 ` Anshuman Khandual
2020-07-02 14:03 ` Catalin Marinas
2020-07-02 14:03 ` Catalin Marinas
2020-07-02 14:03 ` Catalin Marinas
2020-07-02 14:03 ` Catalin Marinas
2020-06-18 1:15 ` [PATCH V3 (RESEND) 2/3] mm/sparsemem: Enable vmem_altmap support in vmemmap_alloc_block_buf() Anshuman Khandual
2020-06-18 1:15 ` Anshuman Khandual
2020-06-18 1:15 ` Anshuman Khandual
2020-07-02 14:07 ` Catalin Marinas [this message]
2020-07-02 14:07 ` Catalin Marinas
2020-07-02 14:07 ` Catalin Marinas
2020-07-03 6:32 ` Anshuman Khandual
2020-07-03 6:32 ` Anshuman Khandual
2020-07-03 6:32 ` Anshuman Khandual
2020-07-03 10:43 ` Michael Ellerman
2020-07-03 10:43 ` Michael Ellerman
2020-07-03 10:43 ` Michael Ellerman
2020-06-18 1:15 ` [PATCH V3 (RESEND) 3/3] arm64/mm: Enable vmem_altmap support for vmemmap mappings Anshuman Khandual
2020-06-18 1:15 ` Anshuman Khandual
2020-07-02 14:09 ` Catalin Marinas
2020-07-02 14:09 ` Catalin Marinas
2020-06-18 8:56 ` [PATCH V3 (RESEND) 0/3] arm64: Enable vmemmap mapping from device memory Mike Rapoport
2020-06-18 8:56 ` Mike Rapoport
2020-06-18 8:56 ` Mike Rapoport
2020-06-18 8:56 ` Mike Rapoport
2020-06-18 8:56 ` Mike Rapoport
2020-06-19 1:34 ` Anshuman Khandual
2020-06-19 1:46 ` Anshuman Khandual
2020-06-19 1:34 ` Anshuman Khandual
2020-06-19 1:34 ` Anshuman Khandual
2020-06-19 1:34 ` Anshuman Khandual
2020-06-23 7:39 ` Jia He
2020-06-23 7:39 ` Jia He
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=20200702140752.GF22241@gaia \
--to=catalin.marinas@arm.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=benh@kernel.crashing.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/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.