linux-doc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Schmitz <schmitzmic@gmail.com>
To: Mike Rapoport <rppt@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Greg Ungerer <gerg@linux-m68k.org>,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	Jonathan Corbet <corbet@lwn.net>,
	Matt Turner <mattst88@gmail.com>, Meelis Roos <mroos@linux.ee>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Russell King <linux@armlinux.org.uk>,
	Tony Luck <tony.luck@intel.com>,
	Vineet Gupta <vgupta@synopsys.com>, Will Deacon <will@kernel.org>,
	alpha <linux-alpha@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	Linux MM <linux-mm@kvack.org>,
	arcml <linux-snps-arc@lists.infradead.org>
Subject: Re: [PATCH 11/13] m68k/mm: make node data and node setup depend on CONFIG_DISCONTIGMEM
Date: Thu, 29 Oct 2020 07:14:38 +1300	[thread overview]
Message-ID: <fd55643a-a17b-5a23-4c77-9e832c1e5128@gmail.com> (raw)
In-Reply-To: <20201028111631.GF1428094@kernel.org>

Hi Mike,

On 29/10/20 12:16 AM, 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 <rppt@kernel.org> wrote:
>>> From: Mike Rapoport <rppt@linux.ibm.com>
>>>
>>> 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 CONFIG_SINGLE_MEMORY_CHUNK was implicitly disabled on the ColdFire MMU
>>> variant, although it always presumed a single memory bank. As there is no
>>> actual need for DISCONTIGMEM in this case, make sure that ColdFire MMU
>>> systems set CONFIG_SINGLE_MEMORY_CHUNK to 'y'.
>>>
>>> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
>> Thanks for your patch!
>>
>>> ---
>>>   arch/m68k/Kconfig.cpu           | 6 +++---
>>>   arch/m68k/include/asm/page_mm.h | 2 +-
>>>   arch/m68k/mm/init.c             | 4 ++--
>>>   3 files changed, 6 insertions(+), 6 deletions(-)
>> Is there any specific reason you didn't convert the checks for
>> CONFIG_SINGLE_MEMORY_CHUNK in arch/m68k/kernel/setup_mm.c
> In arch/m68k/kernel/setup_mm.c the CONFIG_SINGLE_MEMORY_CHUNK is needed
> for the case when a system has two banks, the kernel is loaded into the
> second bank and so the first bank cannot be used as normal memory. It
> does not matter what memory model will be used in this case.


That case used to be detected just fine at run time (by dint of the 
second memory chunk having an address below the first; the chunk the 
kernel resides in is always listed first), even without using 
CONFIG_SINGLE_MEMORY_CHUNK.

Unless you changed that behaviour (and I see nothing in your patch that 
would indicate that), this is still true.

Converting the check as Geert suggested, without also adding a test for 
out-of-order memory bank addresses, would implicitly treat DISCONTIGMEM 
as  SINGLE_MEMORY_CHUNK, regardless of bank ordering. I don't think that 
is what we really want?

Cheers,

     Michael


>
>> and arch/m68k/include/asm/virtconvert.h?
>   
> I remember I had build errors and troubles with include file
> dependencies if I changed it there, but I might be mistaken. I'll
> recheck again.
>
>> Gr{oetje,eeting}s,
>>
>>                          Geert
>>
>> -- 
>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>>
>> In personal conversations with technical people, I call myself a hacker. But
>> when I'm talking to journalists I just say "programmer" or something like that.
>>                                  -- Linus Torvalds

  reply	other threads:[~2020-10-28 22:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-27 11:29 [PATCH 00/13] arch, mm: deprecate DISCONTIGMEM Mike Rapoport
2020-10-27 11:29 ` [PATCH 01/13] alpha: switch from DISCONTIGMEM to SPARSEMEM Mike Rapoport
2020-10-27 11:29 ` [PATCH 02/13] ia64: remove custom __early_pfn_to_nid() Mike Rapoport
2020-10-27 11:29 ` [PATCH 03/13] ia64: remove 'ifdef CONFIG_ZONE_DMA32' statements Mike Rapoport
2020-10-27 11:29 ` [PATCH 04/13] ia64: discontig: paging_init(): remove local max_pfn calculation Mike Rapoport
2020-10-27 11:29 ` [PATCH 05/13] ia64: split virtual map initialization out of paging_init() Mike Rapoport
2020-10-27 11:29 ` [PATCH 06/13] ia64: forbid using VIRTUAL_MEM_MAP with FLATMEM Mike Rapoport
2020-10-27 11:29 ` [PATCH 07/13] ia64: make SPARSEMEM default and disable DISCONTIGMEM Mike Rapoport
2020-12-12 16:01   ` Guenter Roeck
2020-12-13  8:36     ` Mike Rapoport
2020-10-27 11:29 ` [PATCH 08/13] arm: remove CONFIG_ARCH_HAS_HOLES_MEMORYMODEL Mike Rapoport
2020-10-27 11:29 ` [PATCH 09/13] arm, arm64: move free_unused_memmap() to generic mm Mike Rapoport
2020-10-27 11:29 ` [PATCH 10/13] arc: use FLATMEM with freeing of unused memory map instead of DISCONTIGMEM Mike Rapoport
2020-10-27 11:29 ` [PATCH 11/13] m68k/mm: make node data and node setup depend on CONFIG_DISCONTIGMEM Mike Rapoport
2020-10-28  9:25   ` Geert Uytterhoeven
2020-10-28 11:16     ` Mike Rapoport
2020-10-28 18:14       ` Michael Schmitz [this message]
2020-10-28 18:57         ` Mike Rapoport
2020-11-01 16:55       ` Mike Rapoport
2020-10-27 11:29 ` [PATCH 12/13] m68k/mm: enable use of generic memory_model.h for !DISCONTIGMEM Mike Rapoport
2020-10-27 11:29 ` [PATCH 13/13] m68k: deprecate DISCONTIGMEM Mike Rapoport

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=fd55643a-a17b-5a23-4c77-9e832c1e5128@gmail.com \
    --to=schmitzmic@gmail.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=geert@linux-m68k.org \
    --cc=gerg@linux-m68k.org \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=linux-alpha@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-snps-arc@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=mattst88@gmail.com \
    --cc=mroos@linux.ee \
    --cc=rppt@kernel.org \
    --cc=rppt@linux.ibm.com \
    --cc=tony.luck@intel.com \
    --cc=vgupta@synopsys.com \
    --cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).