Messages in this thread | | | From | Nitin Gupta <> | Date | Fri, 20 Oct 2017 18:43:55 -0700 | Subject | Re: [PATCH 1/4] mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS |
| |
On Fri, Oct 20, 2017 at 12:59 PM, Kirill A. Shutemov <kirill.shutemov@linux.intel.com> 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
| |