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=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,FSL_HELO_FAKE,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 B338EC5519F for ; Thu, 12 Nov 2020 19:50:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 199E120825 for ; Thu, 12 Nov 2020 19:50:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Kkl+ct1H" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 199E120825 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 489976B0036; Thu, 12 Nov 2020 14:50:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 413B36B005C; Thu, 12 Nov 2020 14:50:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2DA346B0068; Thu, 12 Nov 2020 14:50:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0037.hostedemail.com [216.40.44.37]) by kanga.kvack.org (Postfix) with ESMTP id E924C6B0036 for ; Thu, 12 Nov 2020 14:50:03 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 93E8F180AD801 for ; Thu, 12 Nov 2020 19:50:03 +0000 (UTC) X-FDA: 77476807086.20.cable84_560839427309 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin20.hostedemail.com (Postfix) with ESMTP id 71214180C07A3 for ; Thu, 12 Nov 2020 19:50:03 +0000 (UTC) X-HE-Tag: cable84_560839427309 X-Filterd-Recvd-Size: 7198 Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Thu, 12 Nov 2020 19:50:02 +0000 (UTC) Received: by mail-pg1-f193.google.com with SMTP id i13so5086092pgm.9 for ; Thu, 12 Nov 2020 11:50:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=NvlbRf6o4iqfxYWdblnv/aYXcxMztTx66EJ83u92hhw=; b=Kkl+ct1H4eqUStLU9rjqUx2uXHw6oc06Umkdhi1K9qNVDj7wtPwdTHOyXbmzOVHV6H /wA8wNhMMfcIheoC7oYLA80Ux3cS153zqz+AyrYrifppG3er4sBAqpGNAbim+UNsE7eA 4PZegvZBWp5ofxzHi/Gh4rfPah3d4f5b9V83E77FMJGS8aK/e1/k1zA67X0FggtjlFq7 eZ90DBq4jA8peJDfF226BD+ezZOPAFzxiucxc4W5i72ashgLF3pPrkNvZigmqZg7Oj0r Y7RxYM1Q3ALKmGxHbeCUcVQerW4RdJh0jtyAAxwXkxUHY9Kn0hfGv+5sTKb/Y98mZ+Er dvnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=NvlbRf6o4iqfxYWdblnv/aYXcxMztTx66EJ83u92hhw=; b=NOfA68hUNyJbSs/0DWKDefqU9gVUqTnax3Ozry76b3dkfSICz3m4ejnp1GEtljgSNL OiZ59L0/K1rkRjcEZIYr/cceHa1nLfhUl2HV5KT3tWX2j56ZFDzpIOBiPu/wdKp73uib LzWLi6aIg8+hgCBzMAgDE8hjbLyZ/dcv5O9FZXdBh1fNCTMsnyFTK70yDlUHuYYtaE0V Zwupeq5Kb0yawMfGHKveyLJRVaJ9svjOdL9iEnKe9yQy1TqyuY8rNz6WezNiY1+MdhHx uA5dGgmmRrm3yaAxf/e+/la8/VAGmXfH7ZwECejk9aS3hytrOW0An7Rcc5DCgrZoN2Nh 89dg== X-Gm-Message-State: AOAM5339Y6CUOh306smibWxvx2VhqYtJJ/6KEL+ee/p8JHnWJDhpUcXB VC3SnQVuQ+D1rddttA/0Y1Y= X-Google-Smtp-Source: ABdhPJzyBwOoOKzay2doG2pjgeOMkJF6Q3yAx34LQnu8xcSIPAN/YcFBYitFLpsjemwpUvJFCnNnyg== X-Received: by 2002:a17:90a:7022:: with SMTP id f31mr794727pjk.213.1605210601467; Thu, 12 Nov 2020 11:50:01 -0800 (PST) Received: from google.com (c-67-188-94-199.hsd1.ca.comcast.net. [67.188.94.199]) by smtp.gmail.com with ESMTPSA id e17sm7824196pfl.216.2020.11.12.11.49.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Nov 2020 11:50:00 -0800 (PST) Date: Thu, 12 Nov 2020 11:49:57 -0800 From: Minchan Kim To: Mike Rapoport Cc: Arnd Bergmann , Stefan Agner , ngupta@vflare.org, Sergey Senozhatsky , Andrew Morton , sjenning@linux.vnet.ibm.com, gregkh , Arnd Bergmann , Linux-MM , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] mm/zsmalloc: include sparsemem.h for MAX_PHYSMEM_BITS Message-ID: <20201112194957.GA123036@google.com> References: <20201108064659.GD301837@kernel.org> <7782fb694a6b0c500e8f32ecf895b2bf@agner.ch> <20201110095806.GH301837@kernel.org> <20201110162155.GA4758@kernel.org> <20201110233620.GA3310704@google.com> <20201111065200.GE4758@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201111065200.GE4758@kernel.org> 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: Hi, On Wed, Nov 11, 2020 at 08:52:00AM +0200, Mike Rapoport wrote: > Hi, > > On Tue, Nov 10, 2020 at 03:36:20PM -0800, Minchan Kim wrote: > > On Tue, Nov 10, 2020 at 06:21:55PM +0200, Mike Rapoport wrote: > > > On Tue, Nov 10, 2020 at 12:21:11PM +0100, Arnd Bergmann wrote: > > > > On Tue, Nov 10, 2020 at 10:58 AM Mike Rapoport wrote: > > > > > > > > > > > > > > asm/sparsemem.h is not available on some architectures. > > > > > > > It's better to use linux/mmzone.h instead. > > > > > > > > Ah, I missed that, too. > > > > > > > > > > Hm, linux/mmzone.h only includes asm/sparsemem.h when CONFIG_SPARSEMEM > > > > > > is enabled. However, on ARM at least I can have configurations without > > > > > > CONFIG_SPARSEMEM and physical address extension on (e.g. > > > > > > multi_v7_defconfig + CONFIG_LPAE + CONFIG_ZSMALLOC). > > > > > > > > > > > > While sparsemem seems to be a good idea with LPAE it really seems not > > > > > > required (see also https://lore.kernel.org/patchwork/patch/567589/). > > > > > > > > > > > > There seem to be also other architectures which define MAX_PHYSMEM_BITS > > > > > > only when SPARSEMEM is enabled, e.g. > > > > > > arch/riscv/include/asm/sparsemem.h... > > > > > > > > > > > > Not sure how to get out of this.. Maybe make ZSMALLOC dependent on > > > > > > SPARSEMEM? It feels a bit silly restricting ZSMALLOC selection only due > > > > > > to a compile time define... > > > > > > > > > > I think we can define MAX_POSSIBLE_PHYSMEM_BITS in one of > > > > > arch/arm/inclide/asm/pgtable-{2,3}level-*.h headers to values supported > > > > > by !LPAE and LPAE. > > > > > > > > Good idea. I wonder what other architectures need the same though. > > > > Here are some I found: > > > > > > > > $ git grep -l PHYS_ADDR_T_64BIT arch | grep Kconfig > > > > arch/arc/Kconfig > > > > arch/arm/mm/Kconfig > > > > arch/mips/Kconfig > > > > arch/powerpc/platforms/Kconfig.cputype > > > > arch/x86/Kconfig > > > > > > > > arch/arc has a CONFIG_ARC_HAS_PAE40 option > > > > arch/riscv has 34-bit addressing in rv32 mode > > > > arch/mips has up to 40 bits with mips32r3 XPA, but I don't know what > > > > supports that > > > > > > > > arch/powerpc has this: > > > > config PHYS_64BIT > > > > bool 'Large physical address support' if E500 || PPC_86xx > > > > depends on (44x || E500 || PPC_86xx) && !PPC_83xx && !PPC_82xx > > > > > > > > Apparently all three (4xx, e500v2, mpc86xx/e600) do 36-bit physical > > > > addressing, but each one has a different page table format. > > > > > > > > Microblaze has physical address extensions, but neither those nor > > > > 64-bit mode have so far made it into the kernel. > > > > > > > > To be on the safe side, we could provoke a compile-time error > > > > when CONFIG_PHYS_ADDR_T_64BIT is set on a 32-bit > > > > architecture, but MAX_POSSIBLE_PHYSMEM_BITS is not set. > > > > > > Maybe compile time warning and a runtime error in zs_init() if 32 bit > > > machine has memory above 4G? > > > > I guess max_pfn will represent maximum pfn configued in the system > > and will not be changed in the runtime. If it's true, how about this? > > (didn't test at all but just for RFC) > > Largely, max_pfn is the maximal pfn at boot time but I don't think it > can be used on systems with memory hotplug. Unless I'm missing > something, with memory hotplug we must have compile-time maximum. > Make sense. I am looking forward to seeing Arnd's patches at this moment. Thanks! Thanks for the help!