From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753491AbdLGOMD (ORCPT ); Thu, 7 Dec 2017 09:12:03 -0500 Received: from mail-bn3nam01on0113.outbound.protection.outlook.com ([104.47.33.113]:47840 "EHLO NAM01-BN3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753664AbdLGOL6 (ORCPT ); Thu, 7 Dec 2017 09:11:58 -0500 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=zi.yan@cs.rutgers.edu; Message-ID: <5A294BE7.4010904@cs.rutgers.edu> Date: Thu, 07 Dec 2017 22:10:47 +0800 From: Zi Yan User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Michal Hocko CC: linux-mm@kvack.org, Naoya Horiguchi , "Kirill A. Shutemov" , Vlastimil Babka , Andrew Morton , Andrea Reale , LKML , Michal Hocko Subject: Re: [RFC PATCH] mm: unclutter THP migration References: <20171207124815.12075-1-mhocko@kernel.org> In-Reply-To: <20171207124815.12075-1-mhocko@kernel.org> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigAE95FC686FE59058D452B4EB" X-Originating-IP: [113.240.164.136] X-ClientProxiedBy: HK2PR04CA0076.apcprd04.prod.outlook.com (10.170.154.148) To BN6PR14MB1650.namprd14.prod.outlook.com (10.171.176.16) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d72c26ac-8985-4787-1397-08d53d7c78e7 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603286);SRVR:BN6PR14MB1650; X-Microsoft-Exchange-Diagnostics: 1;BN6PR14MB1650;3:weXcHrBSAiIwRu+dJxbnJeoseiTcy3lQc1IZuUBqp34P4gf5FaeqjGPkbltP3tbVqN/RtMDzTV11OofJYluC5dPKktMh8TitVkd9uu3hXTBSwiTl/QCyac5ZSiYEHv3w1gGIDiPwuUSQA5SLC0w+vBhWik+U+Mj8DZIrrIswHsEazutHwryYV4LHyOiQFLw7+Zmcd+CUq9Xn1YdMIAnbJUyHlFmdV8dLuPVYZW1wng9dqjSEUzmbjkJ0Tu8ydGaE;25:m2qMGH/oqPTtjFwMguzbHddZ0OYgrK6eX0qRpI5ARuqfuEgtbdsPaQsimSWPbadNvbtYL57Kn/m4E9QdGgwTQDQWgOb4b4WAvJkTMcllb6RkFh6TkP30wKB4vbfedDmN6LeEPPg0ahD61AE7Tc6QTadQdE0VJkJjUyuSzvaT/BlKEKjPAm87i3O32k+2wk07cpnGeUBWAwXX0Sxo1UEykFA2vjALruYMiOTyYdsU2pOo7h14l0KqCyyip/9MWK5rFVr0gYyyV5IpNjDlfACpQ2wVp+ulc0gjyHxZLd7evdhLStD4oc6OtKEV+5xDPoJqjr43PjR8VcpcSaruzzfQjw==;31:E7efIKjyfZQAwz+1zxLCbgm2n2LiqqRAToy22VAVMxZkrewL0rn4L4Ou5GwnHfgw2cHMgzd9wSf/hXkA3ltzt7hZcFz12e2pNRx63hhCzAYb68YG7krglTuttr5swZU1aKEHNwZcSbNAHu5L1cYc2wvFxn8fN6fq+ITI5iaUcpnnrZpDOloP289vDjILKxW7LCp065IhUL0xRu4OUBiAuO16VoaJ8wBxuxkodpkSYPk= X-MS-TrafficTypeDiagnostic: BN6PR14MB1650: X-Microsoft-Exchange-Diagnostics: 1;BN6PR14MB1650;20:n8PQ45pOIkp3aGCG4KhKfC8X8c6g0PEg1Y1Iqamq8Q5JvjV0dOGh67RbYDQc/qSTxtbVo+jCT2W6RkGVc8HdD9GMzC6jIWHy9KNcnyBABqkdzLfFPoCQ//GeZrAcl8UqPlr6/6xQTtPimfQ+gVI8n2cbzpePtdKYVsKGhEjHRwYBHMp4lap6OTmgUApBKIK0uX1D6cmVPs9VTq+o9P5vW0xHGfMjET7IYJ2H3W23wrb6wNw/MdRpAK02vtx2+V0NAauj7ZQK9bSYsLj307E304Da5e4yIlRciKRK958eUcYnmTC7D+oU3Wyxk7zCTssTnd4UuEffz0p2oVN3hFCQhBJlb6b/737v1UCv4/zOBHxo0YLqb8qS4LuGbokdFUCdA6eGmcRsjKXwECSOdVNO256XbkQeHjjVtGyKlQX1NhXVnNnIQ4prDXMwHOimmF5dreS5fvjk/DtTYPCANvdvgwKVU7r8Lvzj8U6DhNz03NFlqqUqOH0zZLfHwQaWdUxG;4:so0E9sXU64gtEvWrlBSAgmNMuQMyUu5fUr+3PnIT/BFY95MKcyeQlLPddSES0UC8SLVwiA4swUzAaSzEBDa63+PADvxJ70/PCBBKDfZKmsK2hY05MeQo6Zmxz/I17LLLT6tsegH8Vm3ZHGR91E9CBYhkDZsWGXb36Y8AS+YKE0VMGn9gksk4i2WsyoF918J7jwXsPRx+2AOGhUN/BC/ll7S0Gq2tGQKW9julgXafbxCa//1knF2xAJ7nyJD+9+kbHRlfvD8g5SyaV9PL4KJCwKqI385l+TNwl9dCemCnLwFjjNII4p62ZPKvMsVb2sl+RTMFnCKT1BoOe2NPEIgKVIjxLlzGmDLr5RpML5Z642hvxTkDzz+0ar0fBeujwIdH X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(189930954265078)(131327999870524)(219752817060721); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(11241501159)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3231022)(3002001)(93006095)(93001095)(6041248)(20161123560025)(20161123558100)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(6072148)(201708071742011);SRVR:BN6PR14MB1650;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:BN6PR14MB1650; X-Forefront-PRVS: 05143A8241 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6049001)(366004)(376002)(346002)(199004)(189003)(24454002)(6486002)(786003)(16526018)(229853002)(316002)(54906003)(117156002)(25786009)(16576012)(76176011)(58126008)(2950100002)(6916009)(45080400002)(4326008)(8936002)(16586007)(21480400003)(66066001)(6246003)(5660300001)(59896002)(42882006)(77096006)(6306002)(80316001)(53936002)(6666003)(478600001)(90366009)(966005)(106356001)(568964002)(33656002)(86362001)(575784001)(83506002)(97736004)(305945005)(105586002)(101416001)(75432002)(3846002)(2906002)(81166006)(8676002)(87266011)(52116002)(5890100001)(84326002)(81156014)(88552002)(6116002)(33964004)(65816011)(7736002)(68736007)(18476003);DIR:OUT;SFP:1102;SCL:1;SRVR:BN6PR14MB1650;H:[192.168.1.103];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjZQUjE0TUIxNjUwOzIzOkpsdVp3OVl6bjYyRW5wT05HRmxJUzhINU8z?= =?utf-8?B?Qi83NnRYQ3hKZm9xc2NXeklCRnA3a2UvMWxuMWErb2NrZ2ZSOHhtemp3RUxu?= =?utf-8?B?YlVDOHdPZzVnRkpYL0RHWEVjT29xM2FDa2dVbzBlUUg2alJUMWs3dkJDREFX?= =?utf-8?B?bXFXMzNLVGNCaUg2eE13Sm9DandWQ2Z4WGdLQWxNRFh3VFdBNXZFbW10WkxJ?= =?utf-8?B?K2p5Ym80Z1NYbTRVTEpPdTEyZDFMSmhOVkVtSlRnUndwMWhoeGwvdXIvQVNt?= =?utf-8?B?WXJBMGVyeVdWS2ZFaVFCSVJCcXAzWWhES3o4OUpPQUZQNC9qZmpaSlJ4NC9X?= =?utf-8?B?Z1NIdXFZYUpRbmxHcEtIVjB4UmJjQnJJMGRYUTQxTmR4NC9xdzAwZWViOGFY?= =?utf-8?B?bUtpRndFN2F1bU1NVjExYldMczF2c0M3bVU0ZkdiMXRydGRBU3ZIN0lHcEZy?= =?utf-8?B?U0swK2hQK0s2bE1aL1owaUkxQVlTbU03MFRyajFBeGhJQzVJZGZtRU1oWFNr?= =?utf-8?B?alJ2cm8vNXVrZ3dXUWtMclZ1TzUxRk9ZR2Z6aDRJcGwxNTNUcWVsVW9yRXlV?= =?utf-8?B?SW1EaWpHUXZUVkhZTEhBT2VJbVdkSWxLT1VLVzFGcjJqdGRxODdVZzdrVnhY?= =?utf-8?B?S21yU1RORjB4TkJPNXJlTC9mTEhZcng0VkZzNGoyRjI3TEpENFdWOVBZYm51?= =?utf-8?B?Z3NWWllkMXlhbjRsSjVoWmh6bkxweXJWSEZ2SGREUFVNbGJ4WTBGYTFCRHlI?= =?utf-8?B?aXI4ak1hQy80MmQ2TEQ4ck1TR0h1Qi9JaklsM1RkbFM2YU9tNk01K1JJRGgw?= =?utf-8?B?UFF5NHUrc0Qrcmw2UVhQc3N1cEFwMjRWSVhCTjhFczdpaGhDbW9XTFFoNWNU?= =?utf-8?B?WDFLb2FSdng3V1RkelROSWF5alJXTnVsOXFFZXBNdVhMSGJkZ0ZHTnNDWEx3?= =?utf-8?B?UGY5TjE3QTJqQ3REVy9NaEo5UWF6cmd5cSs3UlBjMkxMcjBNUkV1VVJLSldp?= =?utf-8?B?STlhYlFMZFNRWWlBZTV2eXBhTURiaU9JTXB1M040bmlQbnlvVzNYR3lZREdS?= =?utf-8?B?bGtCNEJaOVYvV1M0ZjZrRWRvUHJtaWtjazVGL1JwM2FETE56MkdNWUgyeGVZ?= =?utf-8?B?Mk1qR1k4Q2FaY0JtYUVleHlSNEVtUktxRVRxRzZwM2IxVExoc2JIdWtSUXMx?= =?utf-8?B?eHlFMkNESGRRZVpkT0xhU245WDZnS3RqeDdJM1lVMFlUditMNnZwS2g1b20v?= =?utf-8?B?L1BYVFMvOFZMVjFnQ2FlM2NwVjM2aG9MeElUQkdMUVdyUE5SM3NiZ2c5UFJl?= =?utf-8?B?aVgvMVM1YlFlbjR1SDlrL1RDNDI2NWNEWTNodDNObzNxQWhUUFozcmtZZm1B?= =?utf-8?B?S3c2STI5MmhvQmxzck9KWFBUY05jUVlRUFI1TDBNN0pqbGV3Q2F3T09IWEd5?= =?utf-8?B?bkczZHczRE1JNEkwMXAxSFg5dUZJRTdUTlQzTmdWa0RablVBWFdnSElSNGhW?= =?utf-8?B?U2V1cHc4SENqVnFidGtvcDBVL3FBVjJPa2Roa1U0Z3JKMFZiTUM4UXcrb0tP?= =?utf-8?B?bDRDcDhleG5sc0k5NlhJMEJRdXpjRjdFM0NhSE9QczNzVWF1VXZMbWNPSHJD?= =?utf-8?B?a0l4R1NBSEUvSS9ZYlpwNVl6Z1lPZjZkM1dHZUJ0eno5bHoyQkpzUmw2OFZn?= =?utf-8?B?bmdBQ3FOSXBzZjFYbEhFMDJId25OODh3UmIxN3VkTGR6dmxjeXJWV1l6S1Vz?= =?utf-8?B?S0k2NUhDL2VOMk93enEvblppcW42akE3cVJjcHNnSjMwU09xbUVURXNWc0lP?= =?utf-8?B?YlI4ZGxpVzAxZnVxVFFvUi9yMk90V2xlZDNSMHp1c0hBN1I2ZSs0Y2FhaXpB?= =?utf-8?B?MTMyc3FjVkkwb25OZUxaSmlwczhjUjZsMitnbzdCemc4Y2wrcDVVS1NOOGto?= =?utf-8?B?dGYxZW5KNTBoUTFHZzFJWmZOTlVuMHYrRlZuL3BIWGRhVTM2MnBMSlRKcXZW?= =?utf-8?B?OGVaNHpMZW5xcGRUem9USUVtdi9PMloxVUdXQT09?= X-Microsoft-Exchange-Diagnostics: 1;BN6PR14MB1650;6:uyCdKJAYqt+F1ESII8SGSuV4iVQ0dt6d+Gt3TOGjyas/2FhB4xEPeItR6feb6TjnSeL4BNVg9SoxeeczPVOfg+EFlmFwj9v3Ip+/Md/f41mlwTKGNK/STsxCWbOJBdlJJ3wGzmckZFWIkkAlXzUCg4RBQbeiy9QWeqfx8hSc5jc11xKpoMGFa2OtLZ5rUe2lbFohbb+aBFtk/Z5p6dpihoCunE2OkoziYkipDAPjGt23VY3UErtcHL1rqBJ6VpPdF/qklXJ+G+12Csb2b/2A67pA8SK8pDFjxJ7uuu7Oa7cwqAa0Mg9vhletPsul7Sb9ExkG7EMFMreA9gRq5zNQzVOD2v7n6MtAcKFhRNbQFPY=;5:Wuzo0vaayZsRSYFnnJGlQU9dm/aIrohxTKL7asEWtsCFHCn1lEOAGu/Eh6ds3yru4svuKmA/NkGrr5K7X83kfXtobEs18r3rlMDjLu3F0bB3sftPapLdlOqgNaNgnt08O9magMLU/SzcW8ssgglFKtR5m0iy9FIBD1UVmX9lcZA=;24:UYcUU9yaldyJJkthzt/jUnaHja+J/FGd+jdWC4zHTOtttPYnTBui51J1Ei2/dsqX/BDmFLIHdjj0riSlHVd9AJ2HEnfVZS90xs+Y9J9wTfU=;7:y+Huh+93RcDvHApIB4GXwyzyRhWVxAkMPfEP6PTA+DrVJcc+FuO5knEJi79DjTUkZrqaWcXXAKdzaz4EoOzyf2rCI7GMsPzoAeDw4TJQOwpan1QO57zaLR/vf9CDOdpGy0E1GXi4h0fPc5ALQnoHyZTI+nn7rYiECLDUq+mazdHbQb6kh5xOrrumwcdJ+TVb24lFo2zzkOmIebI6abpSFxYN8i8jhFDbw5kRpbtGmR2rQkDoutegELadhbTV1XRd SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cs.rutgers.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2017 14:11:52.4879 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d72c26ac-8985-4787-1397-08d53d7c78e7 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: b92d2b23-4d35-4470-93ff-69aca6632ffe X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1650 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAE95FC686FE59058D452B4EB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Michal, Thanks for sending this out. Michal Hocko wrote: > From: Michal Hocko >=20 > THP migration is hacked into the generic migration with rather > surprising semantic. The migration allocation callback is supposed to > check whether the THP can be migrated at once and if that is not the > case then it allocates a simple page to migrate. unmap_and_move then > fixes that up by spliting the THP into small pages while moving the > head page to the newly allocated order-0 page. Remaning pages are moved= > to the LRU list by split_huge_page. The same happens if the THP > allocation fails. This is really ugly and error prone [1]. >=20 > I also believe that split_huge_page to the LRU lists is inherently > wrong because all tail pages are not migrated. Some callers will just I agree with you that we should try to migrate all tail pages if the THP needs to be split. But this might not be compatible with "getting migration results" in unmap_and_move(), since a caller of migrate_pages() may want to know the status of each page in the migration list via int **result in get_new_page() (e.g. new_page_node()). The caller has no idea whether a THP in its migration list will be split or not, thus, storing migration results might be quite tricky if tail pages are added into the migration list. We need to consider this when we clean up migrate_pages(). > work around that by retrying (e.g. memory hotplug). There are other > pfn walkers which are simply broken though. e.g. madvise_inject_error > will migrate head and then advances next pfn by the huge page size. > do_move_page_to_node_array, queue_pages_range (migrate_pages, mbind), > will simply split the THP before migration if the THP migration is not > supported then falls back to single page migration but it doesn't handl= e > tail pages if the THP migration path is not able to allocate a fresh > THP so we end up with ENOMEM and fail the whole migration which is > a questionable behavior. Page compaction doesn't try to migrate large > pages so it should be immune. >=20 > This patch tries to unclutter the situation by moving the special THP > handling up to the migrate_pages layer where it actually belongs. We > simply split the THP page into the existing list if unmap_and_move fail= s > with ENOMEM and retry. So we will _always_ migrate all THP subpages and= > specific migrate_pages users do not have to deal with this case in a > special way. >=20 > [1] https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fl= kml.kernel.org%2Fr%2F20171121021855.50525-1-zi.yan%40sent.com&data=3D02%7= C01%7Czi.yan%40cs.rutgers.edu%7C1eb88428b6a24e774ee108d53d70cf1f%7Cb92d2b= 234d35447093ff69aca6632ffe%7C1%7C0%7C636482477084480449&sdata=3Dq5nY%2Fe%= 2F8peEiR1YdcdE3PBGBhC%2B4VsCwadBpQGMeBCo%3D&reserved=3D0 >=20 > Signed-off-by: Michal Hocko > --- > Hi, > this is a follow up for [2]. I find this approach much less hackish and= > easier to maintain as well. It also fixes few bugs. I didn't really go > deeply into each migration path and evaluate the user visible bugs but > at least the explicit migration is suboptimal to say the least >=20 > # A simple 100M mmap with MADV_HUGEPAGE and explicit migrate from node = 0 > # to node 1 with results displayed "After pause" > root@test1:~# numactl -m 0 ./map_thp=20 > 7f749d0aa000 bind:0 anon=3D25600 dirty=3D25600 N0=3D25600 kernelpagesiz= e_kB=3D4 > 7f749d0aa000-7f74a34aa000 rw-p 00000000 00:00 0=20 > Size: 102400 kB > Rss: 102400 kB > AnonHugePages: 100352 kB >=20 > After pause > 7f749d0aa000 bind:0 anon=3D25600 dirty=3D25600 N0=3D18602 N1=3D6998 ker= nelpagesize_kB=3D4 > 7f749d0aa000-7f74a34aa000 rw-p 00000000 00:00 0=20 > Size: 102400 kB > Rss: 102400 kB > AnonHugePages: 100352 kB >=20 > root@test1:~# migratepages $(pgrep map_thp) 0 1 > migrate_pages: Cannot allocate memory >=20 > While the migration succeeds with the patch applied even though some TH= P > had to be split and migrated page by page. >=20 > I believe that thp_migration_supported shouldn't be spread outside > of the migration code but I've left few assertion in place. Maybe > they should go as well. I haven't spent too much time on those. My > testing was quite limited and this might still blow up so I would reall= y > appreciate a careful review. >=20 > Thanks! >=20 > [2] https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fl= kml.kernel.org%2Fr%2F20171122130121.ujp6qppa7nhahazh%40dhcp22.suse.cz&dat= a=3D02%7C01%7Czi.yan%40cs.rutgers.edu%7C1eb88428b6a24e774ee108d53d70cf1f%= 7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636482477084480449&sdata=3D9= W%2FW3zgu8lKXEZLoXRi%2BQd9xr1PuuSI%2FRZZrl2ylkdQ%3D&reserved=3D0 >=20 > include/linux/migrate.h | 6 ++++-- > mm/huge_memory.c | 6 ++++++ > mm/memory_hotplug.c | 2 +- > mm/mempolicy.c | 29 ++--------------------------- > mm/migrate.c | 31 ++++++++++++++++++++----------- > 5 files changed, 33 insertions(+), 41 deletions(-) >=20 > diff --git a/include/linux/migrate.h b/include/linux/migrate.h > index a2246cf670ba..ec9503e5f2c2 100644 > --- a/include/linux/migrate.h > +++ b/include/linux/migrate.h > @@ -43,9 +43,11 @@ static inline struct page *new_page_nodemask(struct = page *page, > return alloc_huge_page_nodemask(page_hstate(compound_head(page)), > preferred_nid, nodemask); > =20 > - if (thp_migration_supported() && PageTransHuge(page)) { > - order =3D HPAGE_PMD_ORDER; > + if (PageTransHuge(page)) { > + if (!thp_migration_supported()) > + return NULL; We may not need these two lines, since if thp_migration_supported() is false, unmap_and_move() returns -ENOMEM in your code below, which has the same result of returning NULL here. > gfp_mask |=3D GFP_TRANSHUGE; > + order =3D HPAGE_PMD_ORDER; > } > =20 > if (PageHighMem(page) || (zone_idx(page_zone(page)) =3D=3D ZONE_MOVAB= LE)) > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 7544ce4ef4dc..304f39b9aa5c 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -2425,6 +2425,12 @@ static void __split_huge_page_tail(struct page *= head, int tail, > =20 > page_tail->index =3D head->index + tail; > page_cpupid_xchg_last(page_tail, page_cpupid_last(head)); > + > + /* > + * always add to the tail because some iterators expect new > + * pages to show after the currently processed elements - e.g. > + * migrate_pages > + */ > lru_add_page_tail(head, page_tail, lruvec, list); > } > =20 > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > index d0856ab2f28d..ad0a84aa7b53 100644 > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -1391,7 +1391,7 @@ do_migrate_range(unsigned long start_pfn, unsigne= d long end_pfn) > if (isolate_huge_page(page, &source)) > move_pages -=3D 1 << compound_order(head); > continue; > - } else if (thp_migration_supported() && PageTransHuge(page)) > + } else if (PageTransHuge(page)) > pfn =3D page_to_pfn(compound_head(page)) > + hpage_nr_pages(page) - 1; > =20 > diff --git a/mm/mempolicy.c b/mm/mempolicy.c > index f604b22ebb65..49ecbb50b5f0 100644 > --- a/mm/mempolicy.c > +++ b/mm/mempolicy.c > @@ -446,15 +446,6 @@ static int queue_pages_pmd(pmd_t *pmd, spinlock_t = *ptl, unsigned long addr, > __split_huge_pmd(walk->vma, pmd, addr, false, NULL); > goto out; > } > - if (!thp_migration_supported()) { > - get_page(page); > - spin_unlock(ptl); > - lock_page(page); > - ret =3D split_huge_page(page); > - unlock_page(page); > - put_page(page); > - goto out; > - } > if (!queue_pages_required(page, qp)) { > ret =3D 1; > goto unlock; > @@ -511,22 +502,6 @@ static int queue_pages_pte_range(pmd_t *pmd, unsig= ned long addr, > continue; > if (!queue_pages_required(page, qp)) > continue; > - if (PageTransCompound(page) && !thp_migration_supported()) { > - get_page(page); > - pte_unmap_unlock(pte, ptl); > - lock_page(page); > - ret =3D split_huge_page(page); > - unlock_page(page); > - put_page(page); > - /* Failed to split -- skip. */ > - if (ret) { > - pte =3D pte_offset_map_lock(walk->mm, pmd, > - addr, &ptl); > - continue; > - } > - goto retry; > - } > - > migrate_page_add(page, qp->pagelist, flags); > } > pte_unmap_unlock(pte - 1, ptl); > @@ -947,7 +922,7 @@ static struct page *new_node_page(struct page *page= , unsigned long node, int **x > if (PageHuge(page)) > return alloc_huge_page_node(page_hstate(compound_head(page)), > node); > - else if (thp_migration_supported() && PageTransHuge(page)) { > + else if (PageTransHuge(page)) { > struct page *thp; > =20 > thp =3D alloc_pages_node(node, > @@ -1123,7 +1098,7 @@ static struct page *new_page(struct page *page, u= nsigned long start, int **x) > if (PageHuge(page)) { > BUG_ON(!vma); > return alloc_huge_page_noerr(vma, address, 1); > - } else if (thp_migration_supported() && PageTransHuge(page)) { > + } else if (PageTransHuge(page)) { > struct page *thp; > =20 > thp =3D alloc_hugepage_vma(GFP_TRANSHUGE, vma, address, > diff --git a/mm/migrate.c b/mm/migrate.c > index 4d0be47a322a..ed21642a5c1d 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -1139,6 +1139,9 @@ static ICE_noinline int unmap_and_move(new_page_t= get_new_page, > int *result =3D NULL; > struct page *newpage; > =20 > + if (!thp_migration_supported() && PageTransHuge(page)) > + return -ENOMEM; > + > newpage =3D get_new_page(page, private, &result); > if (!newpage) > return -ENOMEM; > @@ -1160,14 +1163,6 @@ static ICE_noinline int unmap_and_move(new_page_= t get_new_page, > goto out; > } > =20 > - if (unlikely(PageTransHuge(page) && !PageTransHuge(newpage))) { > - lock_page(page); > - rc =3D split_huge_page(page); > - unlock_page(page); > - if (rc) > - goto out; > - } > - > rc =3D __unmap_and_move(page, newpage, force, mode); > if (rc =3D=3D MIGRATEPAGE_SUCCESS) > set_page_owner_migrate_reason(newpage, reason); > @@ -1395,6 +1390,7 @@ int migrate_pages(struct list_head *from, new_pag= e_t get_new_page, > retry =3D 0; > =20 > list_for_each_entry_safe(page, page2, from, lru) { > +retry: > cond_resched(); > =20 > if (PageHuge(page)) > @@ -1408,6 +1404,21 @@ int migrate_pages(struct list_head *from, new_pa= ge_t get_new_page, > =20 > switch(rc) { > case -ENOMEM: > + /* > + * THP migration might be unsupported or the > + * allocation could've failed so we should > + * retry on the same page with the THP split > + * to base pages. > + */ > + if (PageTransHuge(page)) { > + lock_page(page); > + rc =3D split_huge_page_to_list(page, from); > + unlock_page(page); > + if (!rc) { > + list_safe_reset_next(page, page2, lru); > + goto retry; > + } > + } > nr_failed++; > goto out; > case -EAGAIN: > @@ -1470,7 +1481,7 @@ static struct page *new_page_node(struct page *p,= unsigned long private, > if (PageHuge(p)) > return alloc_huge_page_node(page_hstate(compound_head(p)), > pm->node); > - else if (thp_migration_supported() && PageTransHuge(p)) { > + else if (PageTransHuge(p)) { > struct page *thp; > =20 > thp =3D alloc_pages_node(pm->node, > @@ -1517,8 +1528,6 @@ static int do_move_page_to_node_array(struct mm_s= truct *mm, > =20 > /* FOLL_DUMP to ignore special (like zero) pages */ > follflags =3D FOLL_GET | FOLL_DUMP; > - if (!thp_migration_supported()) > - follflags |=3D FOLL_SPLIT; > page =3D follow_page(vma, pp->addr, follflags); > =20 > err =3D PTR_ERR(page); Other than the concern of "getting migration results" and two lines of code I mentioned above, the rest of the code looks good to me. --=20 Best Regards, Yan Zi --------------enigAE95FC686FE59058D452B4EB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJaKUwOAAoJEEGLLxGcTqbM91MH/1Gw9tzmmNEFGBqY+JWF7Fny /yyQH67uh3dH5x7orhvDEI0NBKOYdc2nTj4af90zFTzXBiSS5ewIXQzpRGFdsGtP b1WoT2M2s8nfassznParMV/QntcToB3DEdM27RPdIKS3364t2TDN187y2dfM4hwe bD3kKPaFGgqQpFU0ZoHg7bth+Ax8zpEGhWVPSDphDDd5fHbl9AvBVSAtdBqQc7Xd hIW3ZcA8gaP0BAYV7oNARktHbtMbItaXi6pzR9NitNEzeTsh9MWkHpFKjlpmcptZ yDd/NonCHCCky/lYYoy+Gbq6GD92ZLXNrTVLb+I1mkBU70oOWYxzkPE8XiG63Mc= =153F -----END PGP SIGNATURE----- --------------enigAE95FC686FE59058D452B4EB--