On 2/16/21 6:49 PM, Mike Rapoport wrote:
> Hi Vlastimil,
>
> On Tue, Feb 16, 2021 at 05:39:12PM +0100, Vlastimil Babka wrote:
>>
>>
>> So, Andrea could you please check if this fixes the original
>> fast_isolate_around() issue for you? With the VM_BUG_ON not removed, DEBUG_VM
>> enabled, no
Hi Vlastimil,
On Tue, Feb 16, 2021 at 05:39:12PM +0100, Vlastimil Babka wrote:
>
>
> So, Andrea could you please check if this fixes the original
> fast_isolate_around() issue for you? With the VM_BUG_ON not removed, DEBUG_VM
> enabled, no changes to struct page initialization...
> It relies on
On 2/16/21 2:11 PM, Michal Hocko wrote:
> On Tue 16-02-21 13:34:56, Vlastimil Babka wrote:
>> On 2/16/21 12:01 PM, Mike Rapoport wrote:
>> >>
>> >> I do understand that. And I am not objecting to the patch. I have to
>> >> confess I haven't digested it yet. Any changes to early memory
>> >>
On Tue 16-02-21 13:34:56, Vlastimil Babka wrote:
> On 2/16/21 12:01 PM, Mike Rapoport wrote:
> >>
> >> I do understand that. And I am not objecting to the patch. I have to
> >> confess I haven't digested it yet. Any changes to early memory
> >> intialization have turned out to be subtle and
On 2/16/21 1:34 PM, Vlastimil Babka wrote:
> On 2/16/21 12:01 PM, Mike Rapoport wrote:
>>>
>>> I do understand that. And I am not objecting to the patch. I have to
>>> confess I haven't digested it yet. Any changes to early memory
>>> intialization have turned out to be subtle and corner cases
On 2/16/21 12:01 PM, Mike Rapoport wrote:
>>
>> I do understand that. And I am not objecting to the patch. I have to
>> confess I haven't digested it yet. Any changes to early memory
>> intialization have turned out to be subtle and corner cases only pop up
>> later. This is almost impossible to
On Tue 16-02-21 13:01:54, Mike Rapoport wrote:
> On Tue, Feb 16, 2021 at 09:33:20AM +0100, Michal Hocko wrote:
> > On Mon 15-02-21 23:24:40, Mike Rapoport wrote:
> > > On Mon, Feb 15, 2021 at 10:00:31AM +0100, Michal Hocko wrote:
> > > > On Sun 14-02-21 20:00:16, Mike Rapoport wrote:
> > > > > On
On Mon, Feb 15, 2021 at 09:45:30AM +0100, David Hildenbrand wrote:
> On 14.02.21 18:29, Mike Rapoport wrote:
> > On Fri, Feb 12, 2021 at 10:56:19AM +0100, David Hildenbrand wrote:
> > > On 12.02.21 10:55, David Hildenbrand wrote:
> > > > On 08.02.21 12:08, Mike Rapoport wrote:
> > > > > +#ifdef
On Tue, Feb 16, 2021 at 09:33:20AM +0100, Michal Hocko wrote:
> On Mon 15-02-21 23:24:40, Mike Rapoport wrote:
> > On Mon, Feb 15, 2021 at 10:00:31AM +0100, Michal Hocko wrote:
> > > On Sun 14-02-21 20:00:16, Mike Rapoport wrote:
> > > > On Fri, Feb 12, 2021 at 02:18:20PM +0100, Michal Hocko
On Mon 15-02-21 23:24:40, Mike Rapoport wrote:
> On Mon, Feb 15, 2021 at 10:00:31AM +0100, Michal Hocko wrote:
> > On Sun 14-02-21 20:00:16, Mike Rapoport wrote:
> > > On Fri, Feb 12, 2021 at 02:18:20PM +0100, Michal Hocko wrote:
> >
> > > We can correctly set the zone links for the reserved
On Mon, Feb 15, 2021 at 10:00:31AM +0100, Michal Hocko wrote:
> On Sun 14-02-21 20:00:16, Mike Rapoport wrote:
> > On Fri, Feb 12, 2021 at 02:18:20PM +0100, Michal Hocko wrote:
>
> > We can correctly set the zone links for the reserved pages for holes in the
> > middle of a zone based on the
On 15.02.21 10:00, Michal Hocko wrote:
On Sun 14-02-21 20:00:16, Mike Rapoport wrote:
On Fri, Feb 12, 2021 at 02:18:20PM +0100, Michal Hocko wrote:
On Fri 12-02-21 11:42:15, David Hildenbrand wrote:
On 12.02.21 11:33, Michal Hocko wrote:
[...]
I have to digest this but my first impression
On Sun 14-02-21 20:00:16, Mike Rapoport wrote:
> On Fri, Feb 12, 2021 at 02:18:20PM +0100, Michal Hocko wrote:
> > On Fri 12-02-21 11:42:15, David Hildenbrand wrote:
> > > On 12.02.21 11:33, Michal Hocko wrote:
> > [...]
> > > > I have to digest this but my first impression is that this is more
On 14.02.21 18:29, Mike Rapoport wrote:
On Fri, Feb 12, 2021 at 10:56:19AM +0100, David Hildenbrand wrote:
On 12.02.21 10:55, David Hildenbrand wrote:
On 08.02.21 12:08, Mike Rapoport wrote:
+#ifdef CONFIG_SPARSEMEM
+ /*
+* Sections in the memory map may not match actual
On Fri, Feb 12, 2021 at 02:18:20PM +0100, Michal Hocko wrote:
> On Fri 12-02-21 11:42:15, David Hildenbrand wrote:
> > On 12.02.21 11:33, Michal Hocko wrote:
> [...]
> > > I have to digest this but my first impression is that this is more heavy
> > > weight than it needs to. Pfn walkers should
On Fri, Feb 12, 2021 at 10:56:19AM +0100, David Hildenbrand wrote:
> On 12.02.21 10:55, David Hildenbrand wrote:
> > On 08.02.21 12:08, Mike Rapoport wrote:
> > > +#ifdef CONFIG_SPARSEMEM
> > > + /*
> > > + * Sections in the memory map may not match actual populated
> > > + * memory, extend the
On Fri 12-02-21 11:42:15, David Hildenbrand wrote:
> On 12.02.21 11:33, Michal Hocko wrote:
[...]
> > I have to digest this but my first impression is that this is more heavy
> > weight than it needs to. Pfn walkers should normally obey node range at
> > least. The first pfn is usually excluded
On 12.02.21 11:33, Michal Hocko wrote:
On Mon 08-02-21 13:08:20, 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
On Fri 12-02-21 11:16:28, David Hildenbrand wrote:
> On 12.02.21 11:11, Michal Hocko wrote:
> > On Fri 12-02-21 10:56:19, David Hildenbrand wrote:
> > > On 12.02.21 10:55, David Hildenbrand wrote:
> > > > On 08.02.21 12:08, Mike Rapoport wrote:
> > [...]
> > > > > @@ -6519,8 +6581,19 @@ void
On Mon 08-02-21 13:08:20, 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
> reserved
On 12.02.21 11:11, Michal Hocko wrote:
On Fri 12-02-21 10:56:19, David Hildenbrand wrote:
On 12.02.21 10:55, David Hildenbrand wrote:
On 08.02.21 12:08, Mike Rapoport wrote:
[...]
@@ -6519,8 +6581,19 @@ void __init get_pfn_range_for_nid(unsigned int nid,
*end_pfn =
On Fri 12-02-21 10:56:19, David Hildenbrand wrote:
> On 12.02.21 10:55, David Hildenbrand wrote:
> > On 08.02.21 12:08, Mike Rapoport wrote:
[...]
> > > @@ -6519,8 +6581,19 @@ void __init get_pfn_range_for_nid(unsigned int nid,
> > > *end_pfn = max(*end_pfn, this_end_pfn);
> > >
On 12.02.21 10:55, David Hildenbrand wrote:
On 08.02.21 12:08, 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
On 08.02.21 12:08, 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
reserved by the firmware
On Mon, Feb 08, 2021 at 01:11:00PM -0800, Andrew Morton wrote:
> On Mon, 8 Feb 2021 13:08:20 +0200 Mike Rapoport wrote:
>
> > 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
On Mon, 8 Feb 2021 13:08:20 +0200 Mike Rapoport wrote:
> 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
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
27 matches
Mail list logo
