Re: [PATCH 11/13] m68k/mm: make node data and node setup depend on CONFIG_DISCONTIGMEM

2020-11-01 Thread Mike Rapoport
On Wed, Oct 28, 2020 at 01:16:41PM +0200, Mike Rapoport wrote: > Hi Geert, > > On Wed, Oct 28, 2020 at 10:25:49AM +0100, Geert Uytterhoeven wrote: > > Hi Mike, > > > > On Tue, Oct 27, 2020 at 12:31 PM Mike Rapoport wrote: > > > From: Mike Rapoport > > > > > > The pg_data_t node structures and t

[PATCH v2 03/13] ia64: remove 'ifdef CONFIG_ZONE_DMA32' statements

2020-11-01 Thread Mike Rapoport
From: Mike Rapoport After the removal of SN2 platform (commit cf07cb1ff4ea ("ia64: remove support for the SGI SN2 platform") IA-64 always has ZONE_DMA32 and there is no point to guard code with this configuration option. Remove ifdefery associated with CONFIG_ZONE_DMA32 Signed-off-by: Mike Rapo

[PATCH v2 00/13] arch, mm: deprecate DISCONTIGMEM

2020-11-01 Thread Mike Rapoport
From: Mike Rapoport Hi, It's been a while since DISCONTIGMEM is generally considered deprecated, but it is still used by four architectures. This set replaces DISCONTIGMEM with a different way to handle holes in the memory map and marks DISCONTIGMEM configuration as BROKEN in Kconfigs of these a

[PATCH v2 02/13] ia64: remove custom __early_pfn_to_nid()

2020-11-01 Thread Mike Rapoport
From: Mike Rapoport The ia64 implementation of __early_pfn_to_nid() essentially relies on the same data as the generic implementation. The correspondence between memory ranges and nodes is set in memblock during early memory initialization in register_active_ranges() function. The initializatio

[PATCH v2 01/13] alpha: switch from DISCONTIGMEM to SPARSEMEM

2020-11-01 Thread Mike Rapoport
From: Mike Rapoport Enable SPARSEMEM support on alpha and deprecate DISCONTIGMEM. The required changes are mostly around moving duplicated definitions of page access and address conversion macros to a common place and making sure they are available for all memory models. The DISCONTINGMEM suppo

[PATCH v2 04/13] ia64: discontig: paging_init(): remove local max_pfn calculation

2020-11-01 Thread Mike Rapoport
From: Mike Rapoport The maximal PFN in the system is calculated during find_memory() time and it is stored at max_low_pfn then. Use this value in paging_init() and remove the redundant detection of max_pfn in that function. Signed-off-by: Mike Rapoport --- arch/ia64/mm/discontig.c | 5 +

[PATCH v2 09/13] arm, arm64: move free_unused_memmap() to generic mm

2020-11-01 Thread Mike Rapoport
From: Mike Rapoport ARM and ARM64 free unused parts of the memory map just before the initialization of the page allocator. To allow holes in the memory map both architectures overload pfn_valid() and define HAVE_ARCH_PFN_VALID. Allowing holes in the memory map for FLATMEM may be useful for smal

[PATCH v2 05/13] ia64: split virtual map initialization out of paging_init()

2020-11-01 Thread Mike Rapoport
From: Mike Rapoport For both FLATMEM and DISCONTIGMEM/SPARSEMEM the virtual map initialization is spread over paging_init() for no good reason. Split out the bits related to virtual map initialization to a helper functions, one for FLATMEM and another for !FLATMEM configurations. Signed-off-by:

[PATCH v2 08/13] arm: remove CONFIG_ARCH_HAS_HOLES_MEMORYMODEL

2020-11-01 Thread Mike Rapoport
From: Mike Rapoport ARM is the only architecture that defines CONFIG_ARCH_HAS_HOLES_MEMORYMODEL which in turn enables memmap_valid_within() function that is intended to verify existence of struct page associated with a pfn when there are holes in the memory map. However, the ARCH_HAS_HOLES_MEMO

[PATCH v2 06/13] ia64: forbid using VIRTUAL_MEM_MAP with FLATMEM

2020-11-01 Thread Mike Rapoport
From: Mike Rapoport Virtual memory map was intended to avoid wasting memory on the memory map on systems with large holes in the physical memory layout. Long ago it been superseded first by DISCONTIGMEM and then by SPARSEMEM. Moreover, SPARSEMEM_VMEMMAP provide the same functionality in much more

[PATCH v2 11/13] m68k/mm: make node data and node setup depend on CONFIG_DISCONTIGMEM

2020-11-01 Thread Mike Rapoport
From: Mike Rapoport The pg_data_t node structures and their initialization currently depends on !CONFIG_SINGLE_MEMORY_CHUNK. Since they are required only for DISCONTIGMEM make this dependency explicit and replace usage of CONFIG_SINGLE_MEMORY_CHUNK with CONFIG_DISCONTIGMEM where appropriate. The

[PATCH v2 13/13] m68k: deprecate DISCONTIGMEM

2020-11-01 Thread Mike Rapoport
From: Mike Rapoport DISCONTIGMEM was intended to provide more efficient support for systems with holes in their physical address space that FLATMEM did. Yet, it's overhead in terms of the memory consumption seems to overweight the savings on the unused memory map. For a ARAnyM system with 16 MB

[PATCH v2 10/13] arc: use FLATMEM with freeing of unused memory map instead of DISCONTIGMEM

2020-11-01 Thread Mike Rapoport
From: Mike Rapoport Currently ARC uses DISCONTIGMEM to cope with sparse physical memory address space on systems with 2 memory banks. While DISCONTIGMEM avoids wasting memory on unpopulated memory map, it adds both memory and CPU overhead relatively to FLATMEM. Moreover, DISCONTINGMEM is generall

[PATCH v2 07/13] ia64: make SPARSEMEM default and disable DISCONTIGMEM

2020-11-01 Thread Mike Rapoport
From: Mike Rapoport SPARSEMEM memory model suitable for systems with large holes in their phyiscal memory layout. With SPARSEMEM_VMEMMAP enabled it provides pfn_to_page() and page_to_pfn() as fast as FLATMEM. Make it the default memory model for IA-64 and disable DISCONTIGMEM which is considered

[PATCH v2 12/13] m68k/mm: enable use of generic memory_model.h for !DISCONTIGMEM

2020-11-01 Thread Mike Rapoport
From: Mike Rapoport The pg_data_map and pg_data_table arrays as well as page_to_pfn() and pfn_to_page() are required only for DISCONTIGMEM. Other memory models can use the generic definitions in asm-generic/memory_model.h. Signed-off-by: Mike Rapoport --- arch/m68k/Kconfig.cpu |

Re: [patch V2 00/18] mm/highmem: Preemptible variant of kmap_atomic & friends

2020-11-01 Thread Thomas Gleixner
On Thu, Oct 29 2020 at 23:18, Thomas Gleixner wrote: > > There is also a still to be investigated question from Linus on the initial > posting versus the per cpu / per task mapping stack depth which might need > to be made larger due to the ability to take page faults within a mapping > region. I