vger.kernel.org
> Cc: linux...@lists.infradead.org
> Cc: linux-a...@vger.kernel.org
> Cc: linux...@kvack.org
> Suggested-by: Linus Torvalds
> Signed-off-by: Rick Edgecombe
> Link:
> https://lore.kernel.org/lkml/CAHk-=wizjsu7c9sfyzb3q04108stghff2wfbokgccgw7riz...@mail.gmail.com/
; functioality as before.
>
> Here, add wrapper functions ioremap_prot() and iounmap() for arc's
> special operation when ioremap_prot() and iounmap().
>
> Signed-off-by: Baoquan He
> Cc: Vineet Gupta
> Cc: linux-snps-arc@lists.infradead.org
Reviewed-by: Mike Rapoport (IBM)
>
as better to
> optimize by the compiler.
>
> Fixes: 9420f89db2dd ("mm: move most of core MM initialization to
> mm/mm_init.c")
> Cc: l...@lists.linux.dev
> Signed-off-by: Arnd Bergmann
Acked-by: Mike Rapoport (IBM)
> ---
> v2: fix logic bug reported-by: kerne
s we don't know that all pages in this
> folio were cleaned). Enhance the internal flush routines to take the
> number of pages to flush.
>
> Signed-off-by: Matthew Wilcox (Oracle)
> Cc: Vineet Gupta
> Cc: linux-snps-arc@lists.infradead.org
Acked-by: Mike Rapoport (IBM)
> ---
Andrew,
On Sun, Feb 12, 2023 at 10:37:15PM -0800, Guenter Roeck wrote:
> On 2/12/23 17:26, Mike Rapoport wrote:
> > On Sun, Feb 12, 2023 at 08:13:20AM -0800, Guenter Roeck wrote:
> > > On Sun, Jan 29, 2023 at 02:42:35PM +0200, Mike Rapoport wrote:
> > >
On Sun, Feb 12, 2023 at 08:13:20AM -0800, Guenter Roeck wrote:
> On Sun, Jan 29, 2023 at 02:42:35PM +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > Every architecture that supports FLATMEM memory model defines its own
> > version of pfn_va
Hi,
On Sun, Feb 12, 2023 at 09:35:13AM -0800, Guenter Roeck wrote:
> Hi,
>
> On Sun, Jan 29, 2023 at 02:42:33PM +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > The MMU variant uses generic definitions of page_to_pfn() and
> > pfn_
Hi Guenter,
On Sun, Feb 12, 2023 at 08:13:20AM -0800, Guenter Roeck wrote:
> On Sun, Jan 29, 2023 at 02:42:35PM +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > Every architecture that supports FLATMEM memory model defines its own
> > ve
Hi Conor,
On Tue, Jan 31, 2023 at 05:47:24PM +, Conor Dooley wrote:
> Hey Mike,
>
> On Sun, Jan 29, 2023 at 02:42:35PM +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > Every architecture that supports FLATMEM memory model def
From: "Mike Rapoport (IBM)"
Every architecture that supports FLATMEM memory model defines its own
version of pfn_valid() that essentially compares a pfn to max_mapnr.
Use mips/powerpc version implemented as static inline as a generic
implementation of pfn_valid() and drop its per-ar
From: "Mike Rapoport (IBM)"
There is stale definition of pfn_valid() for DISCONTINGMEM memory model
guarded !FLATMEM && !SPARSEMEM && NUMA ifdefery.
Remove everything but definition of pfn_valid() for FLATMEM.
Signed-off-by: Mike Rapoport (IBM)
---
arch/mi
From: "Mike Rapoport (IBM)"
The MMU variant uses generic definitions of page_to_pfn() and
pfn_to_page(), but !MMU defines them in include/asm/page_no.h for no
good reason.
Include asm-generic/memory_model.h in the common include/asm/page.h and
drop redundant definitions.
Signed-of
From: "Mike Rapoport (IBM)"
Makes it consistent with other architectures and allows for generic
definition of pfn_valid() in asm-generic/memory_model.h with clear override
in arch/arm/include/asm/page.h
Signed-off-by: Mike Rapoport (IBM)
---
arch/arm/include/asm/memory.h | 2 --
From: "Mike Rapoport (IBM)"
Hi,
Every architecture that supports FLATMEM memory model defines its own
version of pfn_valid() that essentially compares a pfn to max_mapnr.
Use mips/powerpc version implemented as static inline as a generic
implementation of pfn_valid() and dr
From: "Mike Rapoport (IBM)"
Every architecture that supports FLATMEM memory model defines its own
version of pfn_valid() that essentially compares a pfn to max_mapnr.
Use mips/powerpc version implemented as static inline as a generic
implementation of pfn_valid() and drop its per-ar
From: "Mike Rapoport (IBM)"
There is stale definition of pfn_valid() for DISCONTINGMEM memory model
guarded !FLATMEM && !SPARSEMEM && NUMA ifdefery.
Remove everything but definition of pfn_valid() for FLATMEM.
Signed-off-by: Mike Rapoport (IBM)
---
arch/mi
From: "Mike Rapoport (IBM)"
The MMU variant uses generic definitions of page_to_pfn() and
pfn_to_page(), but !MMU defines them in include/asm/page_no.h for no
good reason.
Include asm-generic/memory_model.h in the common include/asm/page.h and
drop redundant definitions.
Signed-of
From: "Mike Rapoport (IBM)"
Hi,
Every architecture that supports FLATMEM memory model defines its own
version of pfn_valid() that essentially compares a pfn to max_mapnr.
Use mips/powerpc version implemented as static inline as a generic
implementation of pfn_valid() and dr
On Mon, Nov 29, 2021 at 06:08:10PM -0600, Rob Herring wrote:
> On Sun, Nov 21, 2021 at 08:43:47AM +0200, Mike Rapoport wrote:
> > On Fri, Nov 19, 2021 at 03:58:17PM +0800, Calvin Zhang wrote:
> > > The count of reserved regions in /reserved-memory was limited because
> > &
On Fri, Nov 19, 2021 at 03:58:17PM +0800, Calvin Zhang wrote:
> The count of reserved regions in /reserved-memory was limited because
> the struct reserved_mem array was defined statically. This series sorts
> out reserved memory code and allocates that array from early allocator.
>
> Note:
t Uytterhoeven
> Acked-by: Heiko Carstens
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapoport
> ---
> arch/arc/mm/init.c | 4 ++--
> arch/ia64/mm/contig.c| 2 +-
> arch/ia64/mm/init.c | 2 +-
> arch/m68k/mm/mcfm
; Without "movable_node" set, we don't care and can place kexec-images on
> this memory. In both cases, after successful memory hotunplug, kexec has to
> be re-armed to update the memory map for the second kernel and to place the
> kexec-images somewhere else.
>
> Signed
pluggable. kexec *must not* indicate this memory to
> the second kernel and *must not* place kexec-images on this memory.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapoport
> ---
> include/linux/memblock.h | 16 ++--
> kernel/kexec_file.c
On Fri, Oct 01, 2021 at 10:04:24AM +0200, David Hildenbrand wrote:
> On 30.09.21 23:21, Mike Rapoport wrote:
> > On Wed, Sep 29, 2021 at 06:54:01PM +0200, David Hildenbrand wrote:
> > > On 29.09.21 18:39, Mike Rapoport wrote:
> > > > Hi,
> > > >
> &
On Thu, Sep 30, 2021 at 02:20:33PM -0700, Linus Torvalds wrote:
> On Thu, Sep 30, 2021 at 11:50 AM Mike Rapoport wrote:
> >
> > The first patch is a cleanup of numa_distance allocation in arch_numa I've
> > spotted during the conversion.
> > The second patch is a
On Wed, Sep 29, 2021 at 06:54:01PM +0200, David Hildenbrand wrote:
> On 29.09.21 18:39, Mike Rapoport wrote:
> > Hi,
> >
> > On Mon, Sep 27, 2021 at 05:05:17PM +0200, David Hildenbrand wrote:
> > > Let's add a flag that corresponds to IORESOURCE_SYSRAM
From: Mike Rapoport
Rename memblock_free_ptr() to memblock_free() and use memblock_free()
when freeing a virtual pointer so that memblock_free() will be a
counterpart of memblock_alloc()
The callers are updated with the below semantic patch and manual addition
of (void *) casting to pointers
From: Mike Rapoport
memblock_free_late() is a NOP wrapper for __memblock_free_late(), there is
no point to keep this indirection.
Drop the wrapper and rename __memblock_free_late() to memblock_free_late().
Signed-off-by: Mike Rapoport
---
include/linux/memblock.h | 7 +--
mm/memblock.c
From: Mike Rapoport
free_p2m_page() wrongly passes a virtual pointer to memblock_free() that
treats it as a physical address.
Call memblock_free_ptr() instead that gets a virtual address to free the
memory.
Signed-off-by: Mike Rapoport
Reviewed-by: Juergen Gross
---
arch/x86/xen/p2m.c | 2
From: Mike Rapoport
Memory allocation of numa_distance uses memblock_phys_alloc_range() without
actual range limits, converts the returned physical address to virtual and
then only uses the virtual address for further initialization.
Simplify this by replacing memblock_phys_alloc_range
From: Mike Rapoport
Hi,
Following the discussion on [1] this is the fix for memblock freeing APIs
mismatch.
The first patch is a cleanup of numa_distance allocation in arch_numa I've
spotted during the conversion.
The second patch is a fix for Xen memory freeing on some of the error
paths.
I
Hi,
On Mon, Sep 27, 2021 at 05:05:17PM +0200, David Hildenbrand wrote:
> Let's add a flag that corresponds to IORESOURCE_SYSRAM_DRIVER_MANAGED.
> Similar to MEMBLOCK_HOTPLUG, most infrastructure has to treat such memory
> like ordinary MEMBLOCK_NONE memory -- for example, when selecting memory
>
On Mon, Sep 27, 2021 at 05:05:16PM +0200, David Hildenbrand wrote:
> We want to specify flags when hotplugging memory. Let's prepare to pass
> flags to memblock_add_node() by adjusting all existing users.
>
> Note that when hotplugging memory the system is already up and running
> and we don't
On Thu, Sep 23, 2021 at 03:54:46PM +0200, Christophe Leroy wrote:
>
> Le 23/09/2021 à 14:01, Mike Rapoport a écrit :
> > On Thu, Sep 23, 2021 at 11:47:48AM +0200, Christophe Leroy wrote:
> > >
> > >
> > > Le 23/09/2021 à 09:43, Mike Rapopor
Hi Linus,
On Thu, Sep 23, 2021 at 09:01:46AM -0700, Linus Torvalds wrote:
> On Thu, Sep 23, 2021 at 12:43 AM Mike Rapoport wrote:
> >
> You need to be a LOT more careful.
>
> From a trivial check - exactly because I looked at doing it with a
> script, and decided it's
On Thu, Sep 23, 2021 at 11:47:48AM +0200, Christophe Leroy wrote:
>
>
> Le 23/09/2021 à 09:43, Mike Rapoport a écrit :
> > From: Mike Rapoport
> >
> > For ages memblock_free() interface dealt with physical addresses even
> > despite the existence of memblock
From: Mike Rapoport
For ages memblock_free() interface dealt with physical addresses even
despite the existence of memblock_alloc_xx() functions that return a
virtual pointer.
Introduce memblock_phys_free() for freeing physical ranges and repurpose
memblock_free() to free virtual pointers
From: Mike Rapoport
free_p2m_page() wrongly passes a virtual pointer to memblock_free() that
treats it as a physical address.
Call memblock_free_ptr() instead that gets a virtual address to free the
memory.
Signed-off-by: Mike Rapoport
---
arch/x86/xen/p2m.c | 2 +-
1 file changed, 1
From: Mike Rapoport
Memory allocation of numa_distance uses memblock_phys_alloc_range() without
actual range limits, converts the returned physical address to virtual and
then only uses the virtual address for further initialization.
Simplify this by replacing memblock_phys_alloc_range
From: Mike Rapoport
Hi,
Following the discussion on [1] this is the fix for memblock freeing APIs
mismatch.
The first patch is a cleanup of numa_distance allocation in arch_numa I've
spotted during the conversion.
The second patch is a fix for Xen memory freeing on some of the error
paths
On Mon, Aug 16, 2021 at 12:53:46PM -0700, Vineet Gupta wrote:
> On 8/15/21 2:27 AM, Mike Rapoport wrote:
> > On Thu, Aug 12, 2021 at 04:37:50PM -0700, Vineet Gupta wrote:
> > > ARCv2 MMU is software walked and Linux implements 2 levels of paging:
> > > pgd/pte.
>
On Thu, Aug 12, 2021 at 04:37:50PM -0700, Vineet Gupta wrote:
> ARCv2 MMU is software walked and Linux implements 2 levels of paging: pgd/pte.
> Forthcoming hw will have multiple levels, so this change preps mm code
> for same. It is also fun to try multi levels even on soft-walked code to
>
Heh,
"Don't pollute mmu.h and cache.h with some of ARC internal bootlog/setup
related functions.
move them aside to setup.h"
is still not there :)
On Thu, Aug 12, 2021 at 04:37:37PM -0700, Vineet Gupta wrote:
> Signed-off-by: Vineet Gupta
> ---
> arch/arc/include/asm/cache.h | 4
>
On Thu, Aug 12, 2021 at 04:37:35PM -0700, Vineet Gupta wrote:
> MMU SCRATCH_DATA0 register is intended to cache task pgd. However in
> ARC700 SMP port, it has to be repurposed for reentrant interrupt
> handling, while UP port doesn't. We currently ahandle boe usecases
cleanups to make way for 14/18 and
> 15/18 which actually imeplement the new levels (in existing ARCv2 port)
> and worth a critical eye.
>
> CC'ing some of you guys dealing with page tables for a while :-)
> to spot any obvious gotchas.
There are a couple of small nits here and there,
On Wed, Aug 11, 2021 at 06:37:19PM -0700, Vineet Gupta wrote:
> On 8/11/21 5:31 AM, Mike Rapoport wrote:
> > > +/*
> > > + * For ARC, pgtable_t is not struct page *, but pte_t * (to avoid
> > > + * extraneous page_address() calculations) hence can't use
> > &
On Tue, Aug 10, 2021 at 05:42:49PM -0700, Vineet Gupta wrote:
> Signed-off-by: Vineet Gupta
> ---
> arch/arc/include/asm/page.h| 30 --
> arch/arc/include/asm/pgalloc.h | 7 ++-
> 2 files changed, 22 insertions(+), 15 deletions(-)
>
> diff --git
On Tue, Aug 10, 2021 at 05:42:56PM -0700, Vineet Gupta wrote:
> Signed-off-by: Vineet Gupta
> ---
> arch/arc/include/asm/page.h | 11 +++
> arch/arc/include/asm/pgalloc.h| 22 +
> arch/arc/include/asm/pgtable-levels.h | 45 ---
>
On Tue, Aug 10, 2021 at 05:42:55PM -0700, Vineet Gupta wrote:
> ARCv2 MMU is software walked and Linux implements 2 levels of paging: pgd/pte.
> Forthcoming hw will have multiple levels, so this change preps mm code
> for same. It is also fun to try multi levels even on soft-walked code to
>
I believe a few words here would be useful even for the future version of
yourself ;-)
On Tue, Aug 10, 2021 at 05:42:51PM -0700, Vineet Gupta wrote:
> Signed-off-by: Vineet Gupta
> ---
> arch/arc/kernel/entry.S | 6 --
> arch/arc/mm/tlb.c | 3 +++
> 2 files changed, 3 insertions(+), 6
On Tue, Aug 10, 2021 at 05:42:46PM -0700, Vineet Gupta wrote:
> In the past I've refrained from doing this (atleast 2 times) due to the
^ at least
> slight code bloat due to ABI implications of pte_t etc becoming sttuct
On Tue, Aug 10, 2021 at 05:42:47PM -0700, Vineet Gupta wrote:
> and remove the one off uncached definition for ARC
>
> Signed-off-by: Vineet Gupta
> ---
> arch/arc/include/asm/pgtable.h | 3 ---
> arch/arc/mm/ioremap.c | 3 ++-
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
>
On Tue, Aug 10, 2021 at 05:42:44PM -0700, Vineet Gupta wrote:
> Signed-off-by: Vineet Gupta
> ---
> arch/arc/include/asm/pgtable.h | 23 ---
> arch/arc/mm/fault.c| 2 +-
> 2 files changed, 1 insertion(+), 24 deletions(-)
Shouldn't this be a part of the patch
Hi Vineet,
On Tue, Aug 10, 2021 at 05:42:43PM -0700, Vineet Gupta wrote:
> Signed-off-by: Vineet Gupta
Hmm, this one seems odd. Try https://www.kernel.com/ ;-)
> Signed-off-by: Vineet Gupta
> ---
> arch/arc/include/asm/cache.h | 4
> arch/arc/include/asm/mmu.h | 4
>
On Fri, Jun 11, 2021 at 01:53:48PM -0700, Stephen Brennan wrote:
> Mike Rapoport writes:
> > From: Mike Rapoport
> >
> > There are no architectures that support DISCONTIGMEM left.
> >
> > Remove the configuration option and the dead code it was guarding in the
&
Hi Arnd,
On Wed, Jun 09, 2021 at 01:30:39PM +0200, Arnd Bergmann wrote:
> On Fri, Jun 4, 2021 at 8:49 AM Mike Rapoport wrote:
> >
> > From: Mike Rapoport
> >
> > Hi,
> >
> > SPARSEMEM memory model was supposed to entirely replace DISCONTIGMEM a
>
On Tue, Jun 08, 2021 at 05:25:44PM -0700, Andrew Morton wrote:
> On Tue, 8 Jun 2021 12:13:15 +0300 Mike Rapoport wrote:
>
> > From: Mike Rapoport
> >
> > After removal of DISCINTIGMEM the NEED_MULTIPLE_NODES and NUMA
> > configuration options
From: Mike Rapoport
After removal of the DISCONTIGMEM memory model the FLAT_NODE_MEM_MAP
configuration option is equivalent to FLATMEM.
Drop CONFIG_FLAT_NODE_MEM_MAP and use CONFIG_FLATMEM instead.
Signed-off-by: Mike Rapoport
---
include/linux/mmzone.h | 4 ++--
kernel/crash_core.c| 2
From: Mike Rapoport
After removal of DISCINTIGMEM the NEED_MULTIPLE_NODES and NUMA
configuration options are equivalent.
Drop CONFIG_NEED_MULTIPLE_NODES and use CONFIG_NUMA instead.
Done with
$ sed -i 's/CONFIG_NEED_MULTIPLE_NODES/CONFIG_NUMA/' \
$(git grep -wl
From: Mike Rapoport
Remove description of DISCONTIGMEM from the "Memory Models" document and
update VM sysctl description so that it won't mention DISCONIGMEM.
Signed-off-by: Mike Rapoport
---
Documentation/admin-guide/sysctl/vm.rst | 12 +++
Documentation/vm/memory-model.rst
From: Mike Rapoport
There are several places that mention DISCONIGMEM in comments or have stale
code guarded by CONFIG_DISCONTIGMEM.
Remove the dead code and update the comments.
Signed-off-by: Mike Rapoport
---
arch/ia64/kernel/topology.c | 5 ++---
arch/ia64/mm/numa.c | 5
From: Mike Rapoport
There are no architectures that support DISCONTIGMEM left.
Remove the configuration option and the dead code it was guarding in the
generic memory management code.
Signed-off-by: Mike Rapoport
---
include/asm-generic/memory_model.h | 37
From: Mike Rapoport
DISCONTIGMEM was replaced by FLATMEM with freeing of the unused memory map
in v5.11.
Remove the support for DISCONTIGMEM entirely.
Signed-off-by: Mike Rapoport
Reviewed-by: Geert Uytterhoeven
Acked-by: Geert Uytterhoeven
---
arch/m68k/Kconfig.cpu | 10
From: Mike Rapoport
DISCONTIGMEM was replaced by FLATMEM with freeing of the unused memory map
in v5.11.
Remove the support for DISCONTIGMEM entirely.
Signed-off-by: Mike Rapoport
Acked-by: Vineet Gupta
---
arch/arc/Kconfig | 13
arch/arc/include/asm/mmzone.h | 40
From: Mike Rapoport
Arc does not use DISCONTIGMEM to implement high memory, update the comment
describing how high memory works to reflect this.
Signed-off-by: Mike Rapoport
Acked-by: Vineet Gupta
---
arch/arc/mm/init.c | 13 +
1 file changed, 5 insertions(+), 8 deletions
From: Mike Rapoport
NUMA is marked broken on alpha for more than 15 years and DISCONTIGMEM was
replaced with SPARSEMEM in v5.11.
Remove both NUMA and DISCONTIGMEM support from alpha.
Signed-off-by: Mike Rapoport
---
arch/alpha/Kconfig| 22 ---
arch/alpha/include/asm
From: Mike Rapoport
Hi,
SPARSEMEM memory model was supposed to entirely replace DISCONTIGMEM a
(long) while ago. The last architectures that used DISCONTIGMEM were
updated to use other memory models in v5.11 and it is about the time to
entirely remove DISCONTIGMEM from the kernel.
This set
Hi,
On Mon, Jun 07, 2021 at 10:53:08AM +0200, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Fri, Jun 4, 2021 at 8:50 AM Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > After removal of DISCINTIGMEM the NEED_MULTIPLE_NODES and NUMA
> > configuration opt
Hello Kefeng,
On Fri, Jun 04, 2021 at 03:06:18PM +0800, Kefeng Wang wrote:
> Add setup_initial_init_mm() helper, then use it
> to cleanup the text, data and brk setup code.
>
> v2:
> - change argument from "char *" to "void *" setup_initial_init_mm()
> suggested by Geert Uytterhoeven
> - use
On Fri, Jun 04, 2021 at 02:07:39PM +, Vineet Gupta wrote:
> On 6/3/21 11:49 PM, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > DISCONTIGMEM was replaced by FLATMEM with freeing of the unused memory map
> > in v5.11.
> >
> > Remove the support fo
From: Mike Rapoport
After removal of the DISCONTIGMEM memory model the FLAT_NODE_MEM_MAP
configuration option is equivalent to FLATMEM.
Drop CONFIG_FLAT_NODE_MEM_MAP and use CONFIG_FLATMEM instead.
Signed-off-by: Mike Rapoport
---
include/linux/mmzone.h | 4 ++--
kernel/crash_core.c| 2
From: Mike Rapoport
After removal of DISCINTIGMEM the NEED_MULTIPLE_NODES and NUMA
configuration options are equivalent.
Drop CONFIG_NEED_MULTIPLE_NODES and use CONFIG_NUMA instead.
Done with
$ sed -i 's/CONFIG_NEED_MULTIPLE_NODES/CONFIG_NUMA/' \
$(git grep -wl
From: Mike Rapoport
Remove description of DISCONTIGMEM from the "Memory Models" document and
update VM sysctl description so that it won't mention DISCONIGMEM.
Signed-off-by: Mike Rapoport
---
Documentation/admin-guide/sysctl/vm.rst | 12 +++
Documentation/vm/memory-model.rst
From: Mike Rapoport
There are several places that mention DISCONIGMEM in comments or have stale
code guarded by CONFIG_DISCONTIGMEM.
Remove the dead code and update the comments.
Signed-off-by: Mike Rapoport
---
arch/ia64/kernel/topology.c | 5 ++---
arch/ia64/mm/numa.c | 5
From: Mike Rapoport
There are no architectures that support DISCONTIGMEM left.
Remove the configuration option and the dead code it was guarding in the
generic memory management code.
Signed-off-by: Mike Rapoport
---
include/asm-generic/memory_model.h | 37
From: Mike Rapoport
DISCONTIGMEM was replaced by FLATMEM with freeing of the unused memory map
in v5.11.
Remove the support for DISCONTIGMEM entirely.
Signed-off-by: Mike Rapoport
---
arch/arc/Kconfig | 13
arch/arc/include/asm/mmzone.h | 40
From: Mike Rapoport
Arc does not use DISCONTIGMEM to implement high memory, update the comment
describing how high memory works to reflect this.
Signed-off-by: Mike Rapoport
---
arch/arc/mm/init.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arc/mm
From: Mike Rapoport
NUMA is marked broken on alpha for more than 15 years and DISCONTIGMEM was
replaced with SPARSEMEM in v5.11.
Remove both NUMA and DISCONTIGMEM support from alpha.
Signed-off-by: Mike Rapoport
---
arch/alpha/Kconfig| 22 ---
arch/alpha/include/asm
From: Mike Rapoport
Hi,
SPARSEMEM memory model was supposed to entirely replace DISCONTIGMEM a
(long) while ago. The last architectures that used DISCONTIGMEM were
updated to use other memory models in v5.11 and it is about the time to
entirely remove DISCONTIGMEM from the kernel.
This set
On Wed, Jun 02, 2021 at 01:25:24PM +0200, Geert Uytterhoeven wrote:
> Hi Mike,
>
> On Wed, Jun 2, 2021 at 12:54 PM Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > DISCONTIGMEM was replaced by FLATMEM with freeing of the unused memory map
> > in
From: Mike Rapoport
After removal of the DISCONTIGMEM memory model the FLAT_NODE_MEM_MAP
configuration option is equivalent to FLATMEM.
Drop CONFIG_FLAT_NODE_MEM_MAP and use CONFIG_FLATMEM instead.
Signed-off-by: Mike Rapoport
---
include/linux/mmzone.h | 4 ++--
kernel/crash_core.c| 2
From: Mike Rapoport
After removal of DISCINTIGMEM the NEED_MULTIPLE_NODES and NUMA
configuration options are equivalent.
Drop CONFIG_NEED_MULTIPLE_NODES and use CONFIG_NUMA instead.
Done with
$ sed -i 's/CONFIG_NEED_MULTIPLE_NODES/CONFIG_NUMA/' \
$(git grep -wl
From: Mike Rapoport
Remove description of DISCONTIGMEM from the "Memory Models" document and
update VM sysctl description so that it won't mention DISCONIGMEM.
Signed-off-by: Mike Rapoport
---
Documentation/admin-guide/sysctl/vm.rst | 12 +++
Documentation/vm/memory-model.rst
From: Mike Rapoport
There are no architectures that support DISCONTIGMEM left.
Remove the configuration option and the dead code it was guarding in the
generic memory management code.
Signed-off-by: Mike Rapoport
---
include/asm-generic/memory_model.h | 37
From: Mike Rapoport
DISCONTIGMEM was replaced by FLATMEM with freeing of the unused memory map
in v5.11.
Remove the support for DISCONTIGMEM entirely.
Signed-off-by: Mike Rapoport
---
arch/m68k/Kconfig.cpu | 10 --
arch/m68k/include/asm/page.h| 2 +-
arch/m68k/include
From: Mike Rapoport
DISCONTIGMEM was replaced by FLATMEM with freeing of the unused memory map
in v5.11.
Remove the support for DISCONTIGMEM entirely.
Signed-off-by: Mike Rapoport
---
arch/arc/Kconfig | 13
arch/arc/include/asm/mmzone.h | 40
From: Mike Rapoport
Arc does not use DISCONTIGMEM to implement high memory, update the comment
describing how high memory works to reflect this.
Signed-off-by: Mike Rapoport
---
arch/arc/mm/init.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/arc/mm
From: Mike Rapoport
NUMA is marked broken on alpha for more than 15 years and DISCONTIGMEM was
replaced with SPARSEMEM in v5.11.
Remove both NUMA and DISCONTIGMEM support from alpha.
Signed-off-by: Mike Rapoport
---
arch/alpha/Kconfig| 22 ---
arch/alpha/include/asm
From: Mike Rapoport
Hi,
SPARSEMEM memory model was supposed to entirely replace DISCONTIGMEM a
(long) while ago. The last architectures that used DISCONTIGMEM were
updated to use other memory models in v5.11 and it is about the time to
entirely remove DISCONTIGMEM from the kernel.
This set
Hi,
On Mon, Apr 26, 2021 at 01:10:04PM +0300, Vladimir Isaev wrote:
> Commit 4af22ded0ecf ("arc: fix memory initialization for systems with two
> memory banks") fixed highmem, but not for PAE case when highmem is
> actually bigger than lowmem.
>
> Signed-off-by: V
On Wed, Mar 17, 2021 at 09:52:10AM +0800, Kefeng Wang wrote:
> mem_init_print_info() is called in mem_init() on each architecture,
> and pass NULL argument, so using void argument and move it into mm_init().
>
> Acked-by: Dave Hansen
> Signed-off-by: Kefeng Wang
Acked-by
On Sat, Dec 12, 2020 at 08:01:44AM -0800, Guenter Roeck wrote:
> On Tue, Oct 27, 2020 at 01:29:49PM +0200, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > SPARSEMEM memory model suitable for systems with large holes in their
> > phyiscal memory layout. Wit
On Wed, Dec 02, 2020 at 08:43:26AM +, Christoph Hellwig wrote:
> On Tue, Dec 01, 2020 at 04:33:01PM +0100, Geert Uytterhoeven wrote:
> > > That's a lot of typos in that patch... I wonder why the buildbot hasn't
> > > complained about this. Thanks for fixing this up! I'm going to fold this
> >
Hi Adrian,
On Tue, Dec 01, 2020 at 08:55:37PM +0100, John Paul Adrian Glaubitz wrote:
> Hi Mike!
>
> On 12/1/20 4:07 PM, John Paul Adrian Glaubitz wrote:
> > This fixes the issue for me.
> >
> > Tested-by: John Paul Adrian Glaubitz
>
> I just booted the kernel from the linux-mm branch and I
(added Jens)
On Tue, Dec 01, 2020 at 01:16:05PM +0100, John Paul Adrian Glaubitz wrote:
> Hi Mike!
>
> On 12/1/20 1:10 PM, Mike Rapoport wrote:
> > On Tue, Dec 01, 2020 at 12:35:09PM +0100, John Paul Adrian Glaubitz wrote:
> >> Hi Mike!
> >>
> >>
On Tue, Dec 01, 2020 at 12:35:09PM +0100, John Paul Adrian Glaubitz wrote:
> Hi Mike!
>
> On 12/1/20 11:29 AM, Mike Rapoport wrote:
> > These changes are in linux-mm tree (https://www.ozlabs.org/~akpm/mmotm/
> > with a mirror at https://github.com/hnaz/linux-m
Hi Adrian,
On Tue, Dec 01, 2020 at 10:10:56AM +0100, John Paul Adrian Glaubitz wrote:
> Hi Mike!
>
> On 11/17/20 7:23 AM, Mike Rapoport wrote:
> >> Apologies for the late reply. Is this still relevant for testing?
> >>
> >> I have already successfully tested
Hi Adrian,
On Tue, Nov 17, 2020 at 09:07:25AM +0100, John Paul Adrian Glaubitz wrote:
> Hi Mike!
>
> On 11/17/20 7:23 AM, Mike Rapoport wrote:
> > There were minor differences only for m68k between the versions. I've
> > verified them on ARAnyM but if you have a real mach
On Tue, Nov 17, 2020 at 06:40:16AM +, Vineet Gupta wrote:
> Hi Mike,
>
> On 11/1/20 9:04 AM, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > Currently ARC uses DISCONTIGMEM to cope with sparse physical memory address
> > space on systems with 2 memory
Hi Adrian,
On Tue, Nov 17, 2020 at 06:24:51AM +0100, John Paul Adrian Glaubitz wrote:
> Hi!
>
> On 11/1/20 6:04 PM, Mike Rapoport wrote:
> > It's been a while since DISCONTIGMEM is generally considered deprecated,
> > but it is still used by four architectures. This set
1 - 100 of 334 matches
Mail list logo
