Re: [PATCH] mm: refactor initialization of stuct page for holes in memory layout

2020-12-03 Thread Andrea Arcangeli
Hello, On Thu, Dec 03, 2020 at 08:25:49AM +0200, Mike Rapoport wrote: > On Wed, Dec 02, 2020 at 03:47:36PM -0800, Andrew Morton wrote: > > On Tue, 1 Dec 2020 20:15:02 +0200 Mike Rapoport wrote: > > > > > From: Mike Rapoport > > > > > > There could be struct pages that are not backed by

Re: [PATCH] mm: refactor initialization of stuct page for holes in memory layout

2020-12-02 Thread Mike Rapoport
On Wed, Dec 02, 2020 at 03:47:36PM -0800, Andrew Morton wrote: > On Tue, 1 Dec 2020 20:15:02 +0200 Mike Rapoport wrote: > > > From: Mike Rapoport > > > > There could be struct pages that are not backed by actual physical memory. > > This can happen when the actual memory bank is not a

Re: [PATCH] mm: refactor initialization of stuct page for holes in memory layout

2020-12-02 Thread Andrew Morton
On Tue, 1 Dec 2020 20:15:02 +0200 Mike Rapoport wrote: > From: Mike Rapoport > > There could be struct pages that are not backed by actual physical memory. > This can happen when the actual memory bank is not a multiple of > SECTION_SIZE or when an architecture does not register memory holes

[PATCH] mm: refactor initialization of stuct page for holes in memory layout

2020-12-01 Thread Mike Rapoport
From: Mike Rapoport There could be struct pages that are not backed by actual physical memory. This can happen when the actual memory bank is not a multiple of SECTION_SIZE or when an architecture does not register memory holes reserved by the firmware as memblock.memory. Such pages are