On Fri 15-11-19 15:55:35, Andrew Morton wrote:
> On Tue, 5 Nov 2019 09:43:52 +0100 Michal Hocko <mhocko@xxxxxxxxxx> wrote:
>
> > On Mon 04-11-19 16:51:26, Vincent Whitchurch wrote:
> > > On Thu, Oct 31, 2019 at 08:25:55AM +0100, Michal Hocko wrote:
> > > > On Wed 30-10-19 18:31:23, Michal Hocko wrote:
> > > > [...]
> > > > > What about this? It still aligns to the size but that should be
> > > > > correctly done to the section size level.
> > > > >
> > > > > diff --git a/mm/sparse.c b/mm/sparse.c
> > > > > index 72f010d9bff5..ab1e6175ac9a 100644
> > > > > --- a/mm/sparse.c
> > > > > +++ b/mm/sparse.c
> > > > > @@ -456,8 +456,7 @@ struct page __init *__populate_section_memmap(unsigned long pfn,
> > > > > if (map)
> > > > > return map;
> > > > >
> > > > > - map = memblock_alloc_try_nid(size,
> > > > > - PAGE_SIZE, addr,
> > > > > + map = memblock_alloc_try_nid(size, size, addr,
> > > > > MEMBLOCK_ALLOC_ACCESSIBLE, nid);
> > > > > if (!map)
> > > > > panic("%s: Failed to allocate %lu bytes align=0x%lx nid=%d from=%pa\n",
> > > > > @@ -474,8 +473,13 @@ static void __init sparse_buffer_init(unsigned long size, int nid)
> > > > > {
> > > > > phys_addr_t addr = __pa(MAX_DMA_ADDRESS);
> > > > > WARN_ON(sparsemap_buf); /* forgot to call sparse_buffer_fini()? */
> > > > > + /*
> > > > > + * Pre-allocated buffer is mainly used by __populate_section_memmap
> > > > > + * and we want it to be properly aligned to the section size - this is
> > > > > + * especially the case for VMEMMAP which maps memmap to PMDs
> > > > > + */
> > > > > sparsemap_buf =
> > > > > - memblock_alloc_try_nid_raw(size, PAGE_SIZE,
> > > > > + memblock_alloc_try_nid_raw(size, section_map_size(),
> > > > > addr,
> > > > > MEMBLOCK_ALLOC_ACCESSIBLE, nid);
> > > > > sparsemap_buf_end = sparsemap_buf + size;
> > > >
> > > > Vincent, could you give this a try please? It would be even better if
> > > > you could add some debugging to measure the overhead. Let me know if you
> > > > need any help with a debugging patch.
> > >
> > > I've tested this patch and it works on my platform: The allocations
> > > from sparse_buffer_alloc() now succeed and the fallback path is not
> > > taken.
> >
> > Thanks a lot. I will try to prepare the full patch with a proper
> > changelog sometimes this week.
> >
>
> We're late in -rc7. Should we run with Vincent's original for now?
Yes, that patch is correct on its own. I have still the follow up clean
up on my todo list. I will get to this hopefully soon.
> And I'm wondering why this is -stable -material? You said
>
> : Anyway the patch is OK. Even though this is not a bug strictly
> : speaking it is certainly a suboptimal behavior because zeroying takes
> : time so I would flag this for a stable tree 4.19+. There is no clear
> : Fixes tag to apply (35fd1eb1e8212 would get closest I guess).
>
> I'm not seeing any description of any runtime effect of the bug at
> present. When would unzeroed sparsemem pageframes cause a problem?
> Could they be visible during deferred initialization or mem hotadd?
The main user visible problem is a memory wastage. The overal amount of
memory should be small. I wouldn't call it a stable material.
--
Michal Hocko
SUSE Labs
