Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [RFC] mm/migrate: Consolidate page allocation helper functions
To:     Hugh Dickins <hughd@google.com>,
        Anshuman Khandual <khandual@linux.vnet.ibm.com>
References: <20180130050642.19834-1-khandual@linux.vnet.ibm.com>
 <20180130143635.GF21609@dhcp22.suse.cz>
 <53cf5454-405b-a812-1389-af4fd7527122@linux.vnet.ibm.com>
 <alpine.LSU.2.11.1801302000200.8014@eggly.anvils>
Cc:     Michal Hocko <mhocko@kernel.org>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, akpm@linux-foundation.org
From:   Anshuman Khandual <khandual@linux.vnet.ibm.com>
Date:   Fri, 2 Feb 2018 15:02:49 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <alpine.LSU.2.11.1801302000200.8014@eggly.anvils>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Message-Id: <2fe9bab9-d35d-e3fe-418a-41ab8f981ce8@linux.vnet.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 01/31/2018 09:56 AM, Hugh Dickins wrote:
> On Wed, 31 Jan 2018, Anshuman Khandual wrote:
>> On 01/30/2018 08:06 PM, Michal Hocko wrote:
>>> On Tue 30-01-18 10:36:42, Anshuman Khandual wrote:
>>>> Allocation helper functions for migrate_pages() remmain scattered with
>>>> similar names making them really confusing. Rename these functions based
>>>> on the context for the migration and move them all into common migration
>>>> header. Functionality remains unchanged.
> 
> I agree that their names could be made less confusing (though didn't
> succeed very well when I tried); and maybe a couple of them are general
> enough to be used from more than one callsite, and could well live in
> mm/migrate.c.
> 
> But moving all of page migration's (currently static) new_page allocator
> functions away from the code that relies on their special characteristics
> (probably relayed to them through a private argument), and into a single
> header file, just seems perverse to me.  And likely to be a nuisance when
> adding more in future: private structures having to be made public just
> to make them visible in that shared header file.
> 
> Would it make sense to keep the various functions that may be called by
> rmap_walk() together in one rmap_walk.h?  The different filesystems'
> writepage methods together in one writepage.h?  I don't think so.

Makes sense. Will probably just change the helper names to something
more meaningful (from previous suggestions in this thread) next around.