From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CC973C4363A for ; Wed, 28 Oct 2020 18:57:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2654A24811 for ; Wed, 28 Oct 2020 18:57:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="0wRwxQSg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2654A24811 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6B1CF6B0062; Wed, 28 Oct 2020 14:57:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6607C6B0068; Wed, 28 Oct 2020 14:57:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 52C376B006C; Wed, 28 Oct 2020 14:57:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0236.hostedemail.com [216.40.44.236]) by kanga.kvack.org (Postfix) with ESMTP id 233BD6B0062 for ; Wed, 28 Oct 2020 14:57:54 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id BF8C43625 for ; Wed, 28 Oct 2020 18:57:53 +0000 (UTC) X-FDA: 77422243626.26.chalk16_1d011ce27287 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 9C2591804B65A for ; Wed, 28 Oct 2020 18:57:53 +0000 (UTC) X-HE-Tag: chalk16_1d011ce27287 X-Filterd-Recvd-Size: 6034 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Wed, 28 Oct 2020 18:57:52 +0000 (UTC) Received: from kernel.org (unknown [87.70.96.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1B5552473E; Wed, 28 Oct 2020 18:57:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603911472; bh=zK9DfVuZHDzMdXj+yhDB8KulDOu8wW0+2VHqzzJ4VCs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=0wRwxQSg4yE6tWskIfT82ofwXzSEJ/5NZugomFl0MhuujRXgT16OkYNSNiruGCQgb 4FmuFCHOOX4U7+tixFCp9eSridGpAq2f1ngfZ2ujosWNGX6mwHBQzCWsAku7+1/9jF 4Ekc11AXMUb29fsDTzF2sQtG1jcmaJnC2BBUIYCs= Date: Wed, 28 Oct 2020 20:57:41 +0200 From: Mike Rapoport To: Michael Schmitz Cc: Geert Uytterhoeven , Andrew Morton , Alexey Dobriyan , Catalin Marinas , Greg Ungerer , John Paul Adrian Glaubitz , Jonathan Corbet , Matt Turner , Meelis Roos , Mike Rapoport , Russell King , Tony Luck , Vineet Gupta , Will Deacon , alpha , Linux ARM , "open list:DOCUMENTATION" , Linux FS Devel , "linux-ia64@vger.kernel.org" , Linux Kernel Mailing List , linux-m68k , Linux MM , arcml Subject: Re: [PATCH 11/13] m68k/mm: make node data and node setup depend on CONFIG_DISCONTIGMEM Message-ID: <20201028185741.GI1428094@kernel.org> References: <20201027112955.14157-1-rppt@kernel.org> <20201027112955.14157-12-rppt@kernel.org> <20201028111631.GF1428094@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Oct 29, 2020 at 07:14:38AM +1300, Michael Schmitz wrote: > Hi Mike, >=20 > On 29/10/20 12:16 AM, Mike Rapoport wrote: > > Hi Geert, > >=20 > > On Wed, Oct 28, 2020 at 10:25:49AM +0100, Geert Uytterhoeven wrote: > > > Hi Mike, > > >=20 > > > On Tue, Oct 27, 2020 at 12:31 PM Mike Rapoport wr= ote: > > > > From: Mike Rapoport > > > >=20 > > > > The pg_data_t node structures and their initialization currently = depends on > > > > !CONFIG_SINGLE_MEMORY_CHUNK. Since they are required only for DIS= CONTIGMEM > > > > make this dependency explicit and replace usage of > > > > CONFIG_SINGLE_MEMORY_CHUNK with CONFIG_DISCONTIGMEM where appropr= iate. > > > >=20 > > > > The CONFIG_SINGLE_MEMORY_CHUNK was implicitly disabled on the Col= dFire MMU > > > > variant, although it always presumed a single memory bank. As the= re is no > > > > actual need for DISCONTIGMEM in this case, make sure that ColdFir= e MMU > > > > systems set CONFIG_SINGLE_MEMORY_CHUNK to 'y'. > > > >=20 > > > > Signed-off-by: Mike Rapoport > > > Thanks for your patch! > > >=20 > > > > --- > > > > 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 need= ed > > for the case when a system has two banks, the kernel is loaded into t= he > > 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. >=20 >=20 > That case used to be detected just fine at run time (by dint of the sec= ond > memory chunk having an address below the first; the chunk the kernel re= sides > in is always listed first), even without using CONFIG_SINGLE_MEMORY_CHU= NK. =20 Right, CONFIG_SINGLE_MEMORY_CHUNK in arch/m68k/kernel/setup_mm.c is used to force using a single bank of memory regardless of run time detection.=20 > Unless you changed that behaviour (and I see nothing in your patch that > would indicate that), this is still true. >=20 > Converting the check as Geert suggested, without also adding a test for > out-of-order memory bank addresses, would implicitly treat DISCONTIGMEM= as=A0 > SINGLE_MEMORY_CHUNK, regardless of bank ordering. I don't think that is= what > we really want? It is in a way the case now when !SINGLE_MEMORY_CHUNK =3D=3D DISCONTIGMEM= . So forcing SIGNLE_MEMORY_CHUNK at compile time would also mean forcing FLATMEM. After these changes I think SINGLE_MEMORY_CHUNK is not needed at all. > Cheers, >=20 > =A0=A0=A0 Michael >=20 >=20 > >=20 > > > 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. > >=20 > > > Gr{oetje,eeting}s, > > >=20 > > > Geert > > >=20 > > > --=20 > > > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@li= nux-m68k.org > > >=20 > > > In personal conversations with technical people, I call myself a ha= cker. But > > > when I'm talking to journalists I just say "programmer" or somethin= g like that. > > > -- Linus Torvalds --=20 Sincerely yours, Mike.