Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752596AbeAERPX (ORCPT + 1 other); Fri, 5 Jan 2018 12:15:23 -0500 Received: from resqmta-ch2-12v.sys.comcast.net ([69.252.207.44]:47198 "EHLO resqmta-ch2-12v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752479AbeAERPV (ORCPT ); Fri, 5 Jan 2018 12:15:21 -0500 Date: Fri, 5 Jan 2018 11:15:18 -0600 (CST) From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: Michal Hocko cc: Anshuman Khandual , Andrew Morton , Zi Yan , Naoya Horiguchi , "Kirill A. Shutemov" , Vlastimil Babka , Andrea Reale , linux-mm@kvack.org, LKML Subject: Re: [PATCH 1/3] mm, numa: rework do_pages_move In-Reply-To: <20180105093301.GK2801@dhcp22.suse.cz> Message-ID: References: <20180103082555.14592-1-mhocko@kernel.org> <20180103082555.14592-2-mhocko@kernel.org> <20180105091443.GJ2801@dhcp22.suse.cz> <20180105093301.GK2801@dhcp22.suse.cz> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-CMAE-Envelope: MS4wfAYYbNgYNUHyivFnsxyCw1ry3VgtciVcdOqWvqTjP15jjb9R3Kcj+MMy3N3gwkLwlG7ubGOFgJl7R7VqYRAVyzZBB8Vz90UacK8OWrEQfGEQNBtcKf3a BgQLfXDkaz0NAL/3nGd75XmJMghatZIus7FUZdzNPh3GQgjVsE/5mpQYr3DDkMKYtf3mqVg1yYheUmbhCNp4Z61cZ/+RQC0EqoUcW4YUqA5jy6LCw2NixZx7 3n7kdmCRhO9+u1vDGcSthECHOIV7c/0YpUfBrrEn1ckqtGMylat6WbX1lPXRt97bdkR6Js9LKVm3RkLhlLbjucH6hA+JfbFRCCs6tn5UkdY2IO9lcaRuqkJu x2JyXH2n5U/lk1d98JHy1ZLk1GZG07//VSHmQRUmDCHkc4BYq+8CJEuEXxcQFBpyJysB+hXGqyrFKRZKKUc9kVr/vzjdqtrtdeB9auUfXlMFhcUibRA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Fri, 5 Jan 2018, Michal Hocko wrote: > Yes. I am really wondering because there souldn't anything specific to > improve the situation with patch 2 and 3. Likewise the only overhead > from the patch 1 I can see is the reduced batching of the mmap_sem. But > then I am wondering what would compensate that later... Could you reduce the frequency of taking mmap_sem? Maybe take it when picking a new node and drop it when done with that node before migrating the list of pages? There is the potential of large amounts of pages being migrated and having to take a semaphore on every one of them would create a nice amount of overhead.