On Fri, Oct 20, 2017 at 05:23:46PM +0200, Ingo Molnar wrote: > > * Kirill A. Shutemov <kirill.shute...@linux.intel.com> wrote: > > > On Fri, Oct 20, 2017 at 08:18:53AM +0000, Ingo Molnar wrote: > > > > > > * Kirill A. Shutemov <kir...@shutemov.name> wrote: > > > > > > > On Tue, Oct 03, 2017 at 11:27:54AM +0300, Kirill A. Shutemov wrote: > > > > > On Fri, Sep 29, 2017 at 05:08:15PM +0300, Kirill A. Shutemov wrote: > > > > > > The first bunch of patches that prepare kernel to boot-time > > > > > > switching > > > > > > between paging modes. > > > > > > > > > > > > Please review and consider applying. > > > > > > > > > > Ping? > > > > > > > > Ingo, is there anything I can do to get review easier for you? > > > > > > Yeah, what is the conclusion on the sub-discussion of patch #2: > > > > > > [PATCH 2/6] mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS > > > > > > ... do we want to skip it entirely and use the other 5 patches? > > > > Yes, please. MAX_PHYSMEM_BITS not variable yet in this part of the series. > > > > And I will post some version the patch in the next part, if it will be > > required. > > Could we add TRULY_MAX_PHYSMEM_BITS (with a better name), to be used in > places > where memory footprint is not a big concern?
That's what I did in the patch. See MAX_POSSIBLE_PHYSMEM_BITS. Not sure how good the name is. > Or, could we keep MAX_PHYSMEM_BITS constant, and introduce a _different_ > constant > that is dynamic, and which could be used in the cases where the 5-level > paging > config causes too much memory footprint in the common 4-level paging case? This is more labor intensive case with unclear benefit. Dynamic MAX_PHYSMEM_BITS doesn't cause any issue in waste majority of cases. -- Kirill A. Shutemov
