[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <11c4796f-865e-9e0c-076a-f750d5da0ea7@intel.com>
Date: Sun, 15 Apr 2018 21:36:16 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Baoquan He <bhe@...hat.com>
Cc: linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
pagupta@...hat.com, linux-mm@...ck.org,
kirill.shutemov@...ux.intel.com
Subject: Re: [PATCH v3 4/4] mm/sparse: Optimize memmap allocation during
sparse_init()
On 04/14/2018 07:19 PM, Baoquan He wrote:
>>> Yes, this place is the hardest to understand. The temorary arrays are
>>> allocated beforehand with the size of 'nr_present_sections'. The error
>>> paths you mentioned is caused by allocation failure of mem_map or
>>> map_map, but whatever it's error or success paths, the sections must be
>>> marked as present in memory_present(). Error or success paths happened
>>> in alloc_usemap_and_memmap(), while checking if it's erorr or success
>>> paths happened in the last for_each_present_section_nr() of
>>> sparse_init(), and clear the ms->section_mem_map if it goes along error
>>> paths. This is the key point of this new allocation way.
>> I think you owe some commenting because this is so hard to understand.
> I can arrange and write a code comment above sparse_init() according to
> this patch's git log, do you think it's OK?
>
> Honestly, it took me several days to write code, while I spent more
> than one week to write the patch log. Writing patch log is really a
> headache to me.
I often find the same: writing the code is the easy part. Explaining
why it is right is the hard part.
Powered by blists - more mailing lists