lkml.org 
[lkml]   [2022]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHv2 5/7] x86/mm: Reserve unaccepted memory bitmap
On Tue, Jan 11, 2022 at 11:10:40AM -0800, Dave Hansen wrote:
> On 1/11/22 03:33, Kirill A. Shutemov wrote:
> > Unaccepted memory bitmap is allocated during decompression stage and
> > handed over to main kernel image via boot_params. The bitmap is used to
> > track if memory has been accepted.
> >
> > Reserve unaccepted memory bitmap has to prevent reallocating memory for
> > other means.
>
> I'm having a hard time parsing that changelog, especially the second
> paragraph. Could you give it another shot?

What about this:

Unaccepted memory bitmap is allocated during decompression stage and
handed over to main kernel image via boot_params.

Kernel tracks what memory has been accepted in the bitmap.

Reserve memory where the bitmap is placed to prevent memblock from
re-allocating the memory for other needs.

?

> > + /* Mark unaccepted memory bitmap reserved */
> > + if (boot_params.unaccepted_memory) {
> > + unsigned long size;
> > +
> > + /* One bit per 2MB */
> > + size = DIV_ROUND_UP(e820__end_of_ram_pfn() * PAGE_SIZE,
> > + PMD_SIZE * BITS_PER_BYTE);
> > + memblock_reserve(boot_params.unaccepted_memory, size);
> > + }
>
> Is it OK that the size of the bitmap is inferred from
> e820__end_of_ram_pfn()? Is this OK in the presence of mem= and other things
> that muck with the e820?

Good question. I think we are fine. If kernel is not able to allocate
memory from a part of physical address space we don't need the bitmap for
it either.

--
Kirill A. Shutemov

\
 
 \ /
  Last update: 2022-01-12 20:46    [W:0.146 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site