[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180628063901.GA32539@MiWiFi-R3L-srv>
Date: Thu, 28 Jun 2018 14:39:01 +0800
From: Baoquan He <bhe@...hat.com>
To: Pavel Tatashin <pasha.tatashin@...cle.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
dave.hansen@...el.com, pagupta@...hat.com,
Linux Memory Management List <linux-mm@...ck.org>,
kirill.shutemov@...ux.intel.com
Subject: Re: [PATCH v5 4/4] mm/sparse: Optimize memmap allocation during
sparse_init()
On 06/27/18 at 11:19pm, Pavel Tatashin wrote:
> > Signed-off-by: Baoquan He <bhe@...hat.com>
> >
> > Signed-off-by: Baoquan He <bhe@...hat.com>
>
> Please remove duplicated signed-off
Done.
>
> > if (!usemap) {
> > ms->section_mem_map = 0;
> > + nr_consumed_maps++;
>
> Currently, we do not set ms->section_mem_map to 0 when fail to
> allocate usemap, only when fail to allocate mmap we set
> section_mem_map to 0. I think this is an existing bug.
Yes, found it when changing code. Later in sparse_init(), added checking
to see if usemap is available, otherwise also do "ms->section_mem_map = 0;"
to clear its ->section_mem_map.
Here if want to be perfect, we may need to free the relevant memmap
because usemap is allocated together, memmap could be allocated one
section by one section. I didn't do that because usemap allocation is
smaller one, if that allocation even failed in this early system
initializaiton stage, the kernel won't live long, so don't bother to do
that to complicate code.
>
> Reviewed-by: Pavel Tatashin <pasha.tatashin@...cle.com>
Powered by blists - more mailing lists