From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752618AbdI1Jo3 (ORCPT ); Thu, 28 Sep 2017 05:44:29 -0400 Received: from mail-wr0-f194.google.com ([209.85.128.194]:33564 "EHLO mail-wr0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751088AbdI1Jo1 (ORCPT ); Thu, 28 Sep 2017 05:44:27 -0400 X-Google-Smtp-Source: AOwi7QA55imVmPplsYUkStnHVZFkAQQ7073sBy+cw3wNEPKYyXPMaEAwYDITkEimA1zmqZWRNYSUig== Date: Thu, 28 Sep 2017 11:44:23 +0200 From: Ingo Molnar To: "Kirill A. Shutemov" Cc: Minchan Kim , Nitin Gupta , Sergey Senozhatsky , "Kirill A. Shutemov" , Ingo Molnar , Linus Torvalds , x86@kernel.org, Thomas Gleixner , "H. Peter Anvin" , Andrew Morton , Andy Lutomirski , Cyrill Gorcunov , Borislav Petkov , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv7 02/19] mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS Message-ID: <20170928094423.c75fatvl6rnqzt5n@gmail.com> References: <20170918105553.27914-1-kirill.shutemov@linux.intel.com> <20170918105553.27914-3-kirill.shutemov@linux.intel.com> <20170928081034.g3k3sz7pue7jnzvi@gmail.com> <20170928091954.t74i542dlnejbzty@node.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170928091954.t74i542dlnejbzty@node.shutemov.name> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Kirill A. Shutemov wrote: > On Thu, Sep 28, 2017 at 10:10:34AM +0200, Ingo Molnar wrote: > > > > * Kirill A. Shutemov wrote: > > > > > With boot-time switching between paging mode we will have variable > > > MAX_PHYSMEM_BITS. > > > > > > Let's use the maximum variable possible for CONFIG_X86_5LEVEL=y > > > configuration to define zsmalloc data structures. > > > > > > Signed-off-by: Kirill A. Shutemov > > > Cc: Minchan Kim > > > Cc: Nitin Gupta > > > Cc: Sergey Senozhatsky > > > --- > > > mm/zsmalloc.c | 6 ++++++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c > > > index 7c38e850a8fc..fe22661f2fe5 100644 > > > --- a/mm/zsmalloc.c > > > +++ b/mm/zsmalloc.c > > > @@ -93,7 +93,13 @@ > > > #define MAX_PHYSMEM_BITS BITS_PER_LONG > > > #endif > > > #endif > > > + > > > +#ifdef CONFIG_X86_5LEVEL > > > +/* MAX_PHYSMEM_BITS is variable, use maximum value here */ > > > +#define _PFN_BITS (52 - PAGE_SHIFT) > > > +#else > > > #define _PFN_BITS (MAX_PHYSMEM_BITS - PAGE_SHIFT) > > > +#endif > > > > This is a totally ugly hack, polluting generic MM code with an x86-ism and an > > arbitrary hard-coded constant that would silently lose validity when x86 paging > > gets extended again ... > > Well, yes it's ugly. And I would be glad to find better solution. But I > don't see one. > > And it won't break silently on x86 paging expanding as it won't use > CONFIG_X86_5LEVEL, so we would fallback to MAX_PHYSMEM_BITS - PAGE_SHIFT. > > I worth noting that the code already has x86 hack. See PAE special case > for MAX_PHYSMEM_BITS. Old mistakes don't justify new ones. It's possible to do better: for example if we provide a MAX_POSSIBLE_PHYSMEM_BITS define that is the higher value then code which needs this for sizing can use it? That could eliminate the PAE dependency as well perhaps. Thanks, Ingo