From patchwork Wed Feb 21 09:27:52 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Baolin Wang X-Patchwork-Id: 13565160 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80BC1C54764 for ; Wed, 21 Feb 2024 09:28:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 197716B0074; Wed, 21 Feb 2024 04:28:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 148826B0075; Wed, 21 Feb 2024 04:28:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 036C86B0082; Wed, 21 Feb 2024 04:28:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E828A6B0074 for ; Wed, 21 Feb 2024 04:28:09 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B54E11A0945 for ; Wed, 21 Feb 2024 09:28:09 +0000 (UTC) X-FDA: 81815284698.04.C2849CC Received: from out30-118.freemail.mail.aliyun.com (out30-118.freemail.mail.aliyun.com [115.124.30.118]) by imf05.hostedemail.com (Postfix) with ESMTP id C3131100008 for ; Wed, 21 Feb 2024 09:28:06 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=iP6DBYRf; spf=pass (imf05.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.118 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708507688; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=R/jDsBhNjN3BwyEA1BOhHb8+crI49fZWr9saM6bffNI=; b=PjXPZ57/ukrkktQqUpqMYL9bSXe5b2X7mJ32uo7OPP3VGDSW9IwW4CI7OTPplmnJysXuNz 4gLDyg5XUMySY7kSl+gJX+LamcTx10+UXC7VfksifuAZzcwFi82c3hDFPGiBaEy72QMAsc 5YeOXhjduvL8DcdcFsZLwhM9hEqeRPI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708507688; a=rsa-sha256; cv=none; b=icSAfyKtChsVy5OrC4NYKl+9fa7speBNy+wzwgW9GOgq2sOkbfLEaaDVOhQR0xZbJx6Zc0 84bb+nIA5fNP/sQCrmxLMeM2XM/NrJ6XxtiK/YdzD+9j0+uBw1JOtgd84VjxBSZG1B/gEH b6lY769Mr2tiEuqkmFcVrP4ma37tFT8= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=iP6DBYRf; spf=pass (imf05.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.118 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1708507684; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=R/jDsBhNjN3BwyEA1BOhHb8+crI49fZWr9saM6bffNI=; b=iP6DBYRfHSg1l+PmxlHF3+SSdn3JZBG+7VApp8GGkLd1rj2W9PpGpZZrT2E9AhOzrKbPUq/4iDxtaW+h7qJeuOMGxqcu/6uAun7vUij+8QPnK4lRJydUkdgHzr3lOhndL7lJgWa0/WFU4evMlGtWLc4mm6H2V0we3MWovOTF8Og= X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R101e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045170;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=10;SR=0;TI=SMTPD_---0W0zUu5Y_1708507682; Received: from localhost(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0W0zUu5Y_1708507682) by smtp.aliyun-inc.com; Wed, 21 Feb 2024 17:28:03 +0800 From: Baolin Wang To: akpm@linux-foundation.org Cc: muchun.song@linux.dev, osalvador@suse.de, david@redhat.com, linmiaohe@huawei.com, naoya.horiguchi@nec.com, mhocko@kernel.org, baolin.wang@linux.alibaba.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [RFC PATCH 0/3] make the hugetlb migration strategy consistent Date: Wed, 21 Feb 2024 17:27:52 +0800 Message-Id: X-Mailer: git-send-email 2.39.3 MIME-Version: 1.0 X-Rspamd-Queue-Id: C3131100008 X-Rspam-User: X-Stat-Signature: mnfaak4jet6rrg6wraf7sfn33pd8w635 X-Rspamd-Server: rspam03 X-HE-Tag: 1708507686-45645 X-HE-Meta: U2FsdGVkX18H6k+oLijpDIVAGgR4cgi0+pZb3CGnvHROVf0cNixXQp0sxX0Wv5lRrrGQIQTWraWoLSG9tVpaAVYb3vtJrIRXV5HVn4PRYPf5sMgidu7uYll+/qGQifXyUULz8NtkPwzvSRDheNXiPSf253DK2UWDKVHa4WyevWomZjjQWHUB3MahMHKtw/t7Mdmnn5nrOB+NUeNtUicFnlw5Rz8Gj5rYcFIxSOzgXNQb4T1RVbgqED8aEFt9VG+YCqAS78KCfHlJm8Z+jzWLVnWw/E3XttI72whkteInNRPHZ2qYl752/JBDpHSXf8Iyi2kRBiE/td1UNjads9a3J5aeqxPoaewcslu0afDZUfkrIPtJw3sonXRrYOMXLeLOFUpo9mIKOQp6Iw4KW4C6pOH5+Xf0JQP0x/lrw1TzNlt7qQ34i8mm6zLduhR8UPBTpJBLfOQyZipXK1GTSELFbJOhbgb5a85FoPQQkrIzGtA8Y4DwlbYFrEJCc1ihDZ1KuPiKwvpma4hv/GK0zeCFAyYN2mKKNNZ1wCpHG3TxuzCK5aFojPZCY2ezD0n3n1c4JJXmvDXsTHybNEb+6mt7K71BTS3M/sIIRx1dzNx7FUY2xIo1eWKLR7QqUAxhxp5zm1MKJF1gip6bJIP9cSq2BMs4QOePvw3U07OSQnFAnvTszkGG8cpYoL1Yz7nMiLOwAy8kgwBqPT4PN3AWBj4Q6+ttawINEN7haajsXIcr+8gLle5fz5IcBhJKbx39s1M8pDsFAVBZQUBXGnzG5mBFJGbVYULDF4XHRqr7ip316oHaWgcyCx78kXq9EeO0ZqzoDe5DLYPyf5G4NqjeAJqKlrvSmqyJcMwRaCSC2RgEtwCdyDwyFpmpqYL3zKoKlriU6mBRg8V5dYcY4/hZ+t5P0eOoNGi5WoYywtIQTgBpFPYvQy9RfLcBf3Apr3oqui3hAuIRj4tUps/pYCzVLCi XFxDl904 dit8FwarlyL0bjFTfIlcOpRC78vDFObckrtzs31UE16VsHU9KdS/HxaTDVkoSmqqFWQOpbXo21x4e4sFmbO4pVKr50CEswwRCeA9zB8ytDPj1c0D4z2l2jmasbz70/ZFhVtONJt7/P+JixUiSI9rsLgBXgYe+JflDgzhIXGpDdkPhJswNffgsTI1kp1+dFlCZn4wKaeswaBjYZ0sbNBQccE3huuBMLso9KyK3Ry1I+ogTdtgqDqKcH2zoCft4W1Erp1Ini590WcPN+4TLttXERDQoQw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi, As discussed in previous thread [1], there is an inconsistency when handling hugetlb migration. When handling the migration of freed hugetlb, it prevents fallback to other NUMA nodes in alloc_and_dissolve_hugetlb_folio(). However, when dealing with in-use hugetlb, it allows fallback to other NUMA nodes in alloc_hugetlb_folio_nodemask(), which can break the per-node hugetlb pool and might result in unexpected failures when node bound workloads doesn't get what is asssumed available. This patch set tries to make the hugetlb migration strategy more clear and consistent. Please find details in each patch. [1] https://lore.kernel.org/all/6f26ce22d2fcd523418a085f2c588fe0776d46e7.1706794035.git.baolin.wang@linux.alibaba.com/ Baolin Wang (3): mm: record the migration reason for struct migration_target_control mm: hugetlb: make the hugetlb migration strategy consistent docs: hugetlbpage.rst: add hugetlb migration description Documentation/admin-guide/mm/hugetlbpage.rst | 7 +++++ include/linux/hugetlb.h | 4 +-- mm/gup.c | 1 + mm/hugetlb.c | 28 ++++++++++++++++++-- mm/internal.h | 1 + mm/memory-failure.c | 1 + mm/memory_hotplug.c | 1 + mm/mempolicy.c | 3 ++- mm/migrate.c | 3 ++- mm/page_alloc.c | 1 + mm/vmscan.c | 3 ++- 11 files changed, 46 insertions(+), 7 deletions(-)