From mboxrd@z Thu Jan 1 00:00:00 1970 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 1ED2DC3DA7F for ; Mon, 12 Aug 2024 05:38:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9EAEC6B0092; Mon, 12 Aug 2024 01:38:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 99B106B0098; Mon, 12 Aug 2024 01:38:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 862206B009A; Mon, 12 Aug 2024 01:38:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 65F2B6B0092 for ; Mon, 12 Aug 2024 01:38:09 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id E051C161542 for ; Mon, 12 Aug 2024 05:38:08 +0000 (UTC) X-FDA: 82442487456.16.443057C Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) by imf28.hostedemail.com (Postfix) with ESMTP id 5B69BC000E for ; Mon, 12 Aug 2024 05:38:06 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=EzMhmG+4; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf28.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.9 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723441035; a=rsa-sha256; cv=none; b=nURE5T6wRu5iy/JGsvA38gwlUTHH/1SDyI4wefSEAZyFYxJCHOHTy5k0PdQ5E5I3FudrRR a7X6orAcC/FqTaI0Cfzo36uGCBkIGMveASp5uK6u2YaIfY//jzJJevqIvDlA9ytwESd2N6 ek1TWZl7GFnPcmJqOwMCXHoFYwFoZsk= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=EzMhmG+4; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf28.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.9 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723441035; 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-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=oVvH84XDSg/O5JuwPUeaax5UIHZgqL+fpj4HKdCQXaI=; b=XLIqZfyxexKMh/gFRix8UY6ttNx/Hpv9kWtaszzjsSrMB4Q3eXAk4gHPWfrT/QfE/0pR5O VQjlSc5QEovyNDFF6gebBesBjSUVHl/KwvdMsZ4fQnavfww1mLjeorgn5JSEK3amG6Qarc 9HCigSYj8Mo42dJohdAMzAn3ffXJjZM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1723441086; x=1754977086; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=OtNOl0fu+2Jf+rCsZgmd6Tb1x6JBNKxJW+QUDFkv8XQ=; b=EzMhmG+4XRP0Y4J0KgGzGWyJBnQaEC7cj0aRMI8MbRAvw4x/Ir/bH1t6 pMYDTZu9UbtwIb7aUKFGE+xNkv9EbZRcG4loyc8Rp5rwxclms5a2T/Kqy QuMc4Jt1Kg4Fa6Utv9ngU+4mklv+xU89rfsDmTMbuMWHyWMQBGfqyhe0u S90rVQYlNCADtyvTsJFWHDfEtshyGQRP/OHR6kc3WQ+hTiiBakyfYmbUb oTo/8E+OLXNVcV4hTClZaRkLzDMj6TJTG+bPUz/8GTwzXUGMBYiJX29t7 CWmtoupTZU+eqHmNTTmTVvFUEJ0ArbQ+Lo5bGGOkH9ucKJgEtctL8QZHJ Q==; X-CSE-ConnectionGUID: uPN6wVM6THy4FvaXRs9xow== X-CSE-MsgGUID: bo3D9+jZSn6BNgT/1en9/Q== X-IronPort-AV: E=McAfee;i="6700,10204,11161"; a="44050964" X-IronPort-AV: E=Sophos;i="6.09,282,1716274800"; d="scan'208";a="44050964" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Aug 2024 22:38:04 -0700 X-CSE-ConnectionGUID: wV2CeHnBRbqr8vl/NfZdUg== X-CSE-MsgGUID: 3VG6m94dT5CYRhcl1sAzZQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,282,1716274800"; d="scan'208";a="58710648" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orviesa007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Aug 2024 22:37:58 -0700 From: "Huang, Ying" To: Dev Jain Cc: akpm@linux-foundation.org, shuah@kernel.org, david@redhat.com, willy@infradead.org, ryan.roberts@arm.com, anshuman.khandual@arm.com, catalin.marinas@arm.com, cl@gentwo.org, vbabka@suse.cz, mhocko@suse.com, apopple@nvidia.com, osalvador@suse.de, baolin.wang@linux.alibaba.com, dave.hansen@linux.intel.com, will@kernel.org, baohua@kernel.org, ioworker0@gmail.com, gshan@redhat.com, mark.rutland@arm.com, kirill.shutemov@linux.intel.com, hughd@google.com, aneesh.kumar@kernel.org, yang@os.amperecomputing.com, peterx@redhat.com, broonie@kernel.org, mgorman@techsingularity.net, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH 1/2] mm: Retry migration earlier upon refcount mismatch In-Reply-To: <20240809103129.365029-2-dev.jain@arm.com> (Dev Jain's message of "Fri, 9 Aug 2024 16:01:28 +0530") References: <20240809103129.365029-1-dev.jain@arm.com> <20240809103129.365029-2-dev.jain@arm.com> Date: Mon, 12 Aug 2024 13:34:24 +0800 Message-ID: <87frrauwwv.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Queue-Id: 5B69BC000E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: q91oe91umh6xtok83e6bb3efs8dzxf78 X-HE-Tag: 1723441086-821111 X-HE-Meta: U2FsdGVkX1+ENreg6hfhA7IHkfZ39qSUJzGMhSu246ookKMuclv1s9HedVK8z+Hb28TinxU7C9klTsW9eIJRiTdASwd7bwylCAQ71bduguQExiwjy/PuH310eZtCTI7+Oa1Xevgde28BQuUHcdUuJuNjbAzbCcTr0IU+xUgpQSs8lflE2qsOn5YsD1xjhIvJr/OyXXhQ4thvRWZtC96AjYelEAJbilbKi95XStPFjguvs0ifJO5sr0PBWK/rhaSCZFak5fw30v66ZrFvcZDnMnoAjazjo+ygmDVM9G+eA6XlEnrCYdasgHMbKWETiqOKPGCDUXEG5FuYHNyj4slhvKmkGg6ZmxWp7o9e/BSJeKrof8EhKAISr1zvvjCYHnXZ66LcvEZ38thijKlYf9DEatIIvBPz+0htBmz0Ipzeiab045KZEnvND9z0Y4chLlzmBT29Likd6FsfgJ8DNAN8efjMdqv/Bpi4ZOxMJ2XQGYmhIOv0Du0SY8uD5aca/H6z2P//PDdTfzoLYE03eW48jHmOImrzBzAkBAJh8QY1HkR9Z9XBiYTx7CG0oNmRfuNb9HEHmHwatPm6mC8o7KdVz8bMNHxMhJzs8HIDnilnPYBFwL2G9uvxrgVMaRSEim7QVsrpwacptkopckIegMptYMoaRRTQJ2bQrxstTYcYN064UfEMnWqqIakm8l7QuiesJX4lMOJtljq9Cgh2PBLCbLqamloN3IOoiq9r0JUhaoV0fqONh701mQLGEIuTtDzmFv25UBlD1vBeKUVvUigN3i91yYUW/kxuzeHCd4TlBfR1Enney7HcV0QcgH64Ob06VnnJsaw4l7uNll7w3WWMJlt5EiZptlOGt/aAfyWviG/MayloeokW9X64sboPxyxBF0THz0/+2tv4tBghVV9+5xXveUTL6cx2u5qzCQ10g3UoIGaC4914O3wCPgoZkAH1JSmnNIWDesLUEhlPPKT TMQCtqjv 4/7rTXojOgdgfmu/5pa9BuWRxnZgdUCLwNbZL2JUC2whaYyS7YRh+/YArdMsTCLWEtRGYxeATQUAC6HwHAV6QG8tWfNsKQio7YIphCUon6hCs5/wb+y/qJrlfjHtvukmRlMllUbX58waAgX8ZUyvX6TJ4Q6gx5C7hftgkUMOsEWjJjyMdf7A+QRrh4jzfMblwiNDO0/3x2qvd6AA= 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, Dev, Dev Jain writes: > As already being done in __migrate_folio(), wherein we backoff if the > folio refcount is wrong, make this check during the unmapping phase, upon > the failure of which, the original state of the PTEs will be restored and > the folio lock will be dropped via migrate_folio_undo_src(), any racing > thread will make progress and migration will be retried. > > Signed-off-by: Dev Jain > --- > mm/migrate.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/mm/migrate.c b/mm/migrate.c > index e7296c0fb5d5..477acf996951 100644 > --- a/mm/migrate.c > +++ b/mm/migrate.c > @@ -1250,6 +1250,15 @@ static int migrate_folio_unmap(new_folio_t get_new_folio, > } > > if (!folio_mapped(src)) { > + /* > + * Someone may have changed the refcount and maybe sleeping > + * on the folio lock. In case of refcount mismatch, bail out, > + * let the system make progress and retry. > + */ > + struct address_space *mapping = folio_mapping(src); > + > + if (folio_ref_count(src) != folio_expected_refs(mapping, src)) > + goto out; > __migrate_folio_record(dst, old_page_state, anon_vma); > return MIGRATEPAGE_UNMAP; > } Do you have some test results for this? For example, after applying the patch, the migration success rate increased XX%, etc. My understanding for this issue is that the migration success rate can increase if we undo all changes before retrying. This is the current behavior for sync migration, but not for async migration. If so, we can use migrate_pages_sync() for async migration too to increase success rate? Of course, we need to change the function name and comments. -- Best Regards, Huang, Ying