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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,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 B1E51C55ABD for ; Tue, 10 Nov 2020 15:19:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2404E2076E for ; Tue, 10 Nov 2020 15:19:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="cWZPUcMk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2404E2076E 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 4FD156B0071; Tue, 10 Nov 2020 10:19:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4AE276B0072; Tue, 10 Nov 2020 10:19:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 34E7A6B0073; Tue, 10 Nov 2020 10:19:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0026.hostedemail.com [216.40.44.26]) by kanga.kvack.org (Postfix) with ESMTP id 09A8A6B0071 for ; Tue, 10 Nov 2020 10:19:49 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 9BC0E181AEF09 for ; Tue, 10 Nov 2020 15:19:49 +0000 (UTC) X-FDA: 77468868498.10.crowd07_0d06fb9272f6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin10.hostedemail.com (Postfix) with ESMTP id 4D1C816A0AB for ; Tue, 10 Nov 2020 15:19:49 +0000 (UTC) X-HE-Tag: crowd07_0d06fb9272f6 X-Filterd-Recvd-Size: 5195 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Tue, 10 Nov 2020 15:19:48 +0000 (UTC) Received: from mail-oo1-f49.google.com (mail-oo1-f49.google.com [209.85.161.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 93296207D3 for ; Tue, 10 Nov 2020 15:19:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605021587; bh=8lVT8ZTeoFlItoKh81HPlqRLu1gJHbWcAi9s/4Gzj5k=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=cWZPUcMkGN53XOO0sX/uhI4Z+bD+M9kepq6pEyirF4jKTgg0ab+rb5jSJdWFBBWMu 2f+Qjmvp1LLqKEErSdAtaS4vHvPAOMkwVLJVUUk8YCEKfVlOI1Elnwyou+SPBpZhWK lajAE0l4g5HsJ8RLryW6JEcErM+vTqDKsAL1pP/4= Received: by mail-oo1-f49.google.com with SMTP id f8so2665778oou.0 for ; Tue, 10 Nov 2020 07:19:47 -0800 (PST) X-Gm-Message-State: AOAM533D9CEccd2hNNmGZ6GBOEtDGeocDL2AqnIrUl+l7D1dimLMJhfh y6USW7wMemF5HGhsV1gg9MW9T8OEZyjI0OnKVbI= X-Google-Smtp-Source: ABdhPJxHJ4rn2y+LU64am7Qu4sz45dFM6TgFIYN58j0maUyG4lRin3+55hak13o49DgoPPw2dXXkWGOow1bf4DbIfM8= X-Received: by 2002:a4a:e96d:: with SMTP id i13mr13769802ooe.66.1605021586822; Tue, 10 Nov 2020 07:19:46 -0800 (PST) MIME-Version: 1.0 References: <20201108064659.GD301837@kernel.org> <7782fb694a6b0c500e8f32ecf895b2bf@agner.ch> <20201110095806.GH301837@kernel.org> <48fdc3631bc74dd77fea1a30085c8af9@agner.ch> In-Reply-To: <48fdc3631bc74dd77fea1a30085c8af9@agner.ch> From: Arnd Bergmann Date: Tue, 10 Nov 2020 16:19:30 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm/zsmalloc: include sparsemem.h for MAX_PHYSMEM_BITS To: Stefan Agner Cc: Mike Rapoport , Minchan Kim , ngupta@vflare.org, Sergey Senozhatsky , Andrew Morton , sjenning@linux.vnet.ibm.com, gregkh , Arnd Bergmann , Linux-MM , "linux-kernel@vger.kernel.org" , Russell King - ARM Linux Content-Type: text/plain; charset="UTF-8" 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 Tue, Nov 10, 2020 at 1:24 PM Stefan Agner wrote: > On 2020-11-10 12:21, Arnd Bergmann wrote: > > Good idea. I wonder what other architectures need the same though. > > >> That's what x86 does: > >> > >> $ git grep -w MAX_POSSIBLE_PHYSMEM_BITS arch/ > >> arch/x86/include/asm/pgtable-3level_types.h:#define MAX_POSSIBLE_PHYSMEM_BITS 36 > > > > Doesn't x86 also support a 40-bit addressing mode? I suppose > > those machines that actually used it are long gone. > > > >> arch/x86/include/asm/pgtable_64_types.h:#define MAX_POSSIBLE_PHYSMEM_BITS 52 > >> > >> It seems that actual numbers would be 36 for !LPAE and 40 for LPAE, but > >> I'm not sure about that. > > > > Close enough, yes. > > > > The 36-bit addressing is on !LPAE is only used for early static mappings, > > so I think we can pretend it's always 32-bit. I checked the ARMv8 reference, > > and it says that ARMv8-Aarch32 actually supports 40 bit physical addressing > > both with non-LPAE superpages (short descriptor format) and LPAE (long > > descriptor format), but Linux only does 36-bit addressing on superpages > > as specified for ARMv6/ARMv7 short descriptors. > > Oh so, more than 4GB of memory can be supported by !LPAE systems via > superpages? Wasn't aware of that. Not really, we only really use it for MMIO mappings, and only on the Xscale3 CPU. Support for this was originally added for IXP23xx, and the same core is present in IOP13xx and PXA3xx, but only the last one of these is still supported in mainline, and I don't know if it actually has anything outside of the 32-bit address space (arch/arm/mach-pxa/include/mach/addr-map.h suggests it does not) Russell might remember more details here, and if there is a reason to keep IO_36 support working after we removed IXP23xx back in 2012 and never enabled it for ARMv6 or v7. I suppose removing it would only change a few lines in asm/domain.h, as we'd still want to keep supersection support regardless. > Since only ARM_LPAE selects CONFIG_PHYS_ADDR_T_64BIT it really is safe > to assume 32 bits for non-LPAE systems. > > I guess that would mean adding a #define MAX_POSSIBLE_PHYSMEM_BITS 32 to > arch/arm/include/asm/pgtable-2level.h and a MAX_POSSIBLE_PHYSMEM_BITS 40 > in arch/arm/include/asm/pgtable-3level.h. Seems straight forward and > would solve the problem I had. I can prepare a patch for ARM, not sure > about the other architectures... I think I can help with that once we have agreed on a patch for ARM. Arnd