On Fri, Oct 20, 2017 at 12:59 PM, Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> 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. > > The patch introduces MAX_POSSIBLE_PHYSMEM_BITS to cover such case. > It also suits well to handle PAE special case. > I see that with your upcoming patch, MAX_PHYSMEM_BITS is turned into a variable for x86_64 case as: (pgtable_l5_enabled ? 52 : 46). Even with this change, I don't see a need for this new MAX_POSSIBLE_PHYSMEM_BITS constant. > -#ifndef MAX_PHYSMEM_BITS > -#ifdef CONFIG_HIGHMEM64G > -#define MAX_PHYSMEM_BITS 36 > -#else /* !CONFIG_HIGHMEM64G */ > +#ifndef MAX_POSSIBLE_PHYSMEM_BITS > +#ifdef MAX_PHYSMEM_BITS > +#define MAX_POSSIBLE_PHYSMEM_BITS MAX_PHYSMEM_BITS > +#else This ifdef on HIGHMEM64G is redundant, as x86 already defines MAX_PHYSMEM_BITS = 36 in PAE case. So, all that zsmalloc should do is: #ifndef MAX_PHYSMEM_BITS #define MAX_PHYSMEM_BITS BITS_PER_LONG #endif .. and then no change is needed for rest of derived constants like _PFN_BITS. It is upto every arch to define correct MAX_PHYSMEM_BITS (variable or constant) based on whatever configurations the arch supports. If not defined, zsmalloc picks a reasonable default of BITS_PER_LONG. I will send a patch which makes the change to remove ifdef on CONFIG_HIGHMEM64G. Thanks, Nitin -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
