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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E0CFCD6136 for ; Mon, 9 Oct 2023 20:32:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1377819AbjJIUcq (ORCPT ); Mon, 9 Oct 2023 16:32:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35704 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346654AbjJIUcp (ORCPT ); Mon, 9 Oct 2023 16:32:45 -0400 Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 350859E for ; Mon, 9 Oct 2023 13:32:44 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id A12B15C02B9; Mon, 9 Oct 2023 16:32:43 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 09 Oct 2023 16:32:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sent.com; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:reply-to:sender :subject:subject:to:to; s=fm2; t=1696883563; x=1696969963; bh=JP vpBZP1SSiqvBRF9ydN+g0ZFANiZsdjFQ7+amB/n1s=; b=eXdStKJ2pUQ8PIxQKv v4+49A47wjAImQwoLH2c9IWNdyCam1VBVuLz+McMZoPKxDRdxoOYIRCBRQducQR2 WfM2TuASvkyffQNdk9oFuFANUnk+4AQ/Fue6JYRdYw7XM9EfN/kpfFudR2Z9KM0a FMIeJFp751MvE2jeSz2I5wTB6ZO2UyjsLwlS9dWVyNX2316+O0oAD1Ou2xnKiKJT oQH5iSKi7F3lPORxiGkWp+ZieyeHw3BZepFlgetSkTDJxdmeF1Go4XiO20X09hpL kxK899lKSbaI31hk+OiY6anY+25Wn7VB3cFdYE1OGFxb+7CEO/FeaorveYoarwFT SY8A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1696883563; x=1696969963; bh=J PvpBZP1SSiqvBRF9ydN+g0ZFANiZsdjFQ7+amB/n1s=; b=Ha1tRQ+kVnqQxBJUW 8EXwUIBNS5fH98GQgY8Lpb+aSAXu9/UPJZq5f0z12lKqQ1XPql/iPGB8K+PS8XzG lbPEvqRmWfVWNSWh5wJeuthxxqrcQjN5Jl7/djL/PjOqwLdE86pF+5Eeu4hrJkqI mw5fV36KFlmVg+NnzMxLLNVWOrBUSaBYoGPKngcUiQiEveiBpu9fKBYeMRC0r8L1 G5oCI82lUGZrN2KTGhtS/cbGyqxOGACP5ZdiDKEHscmyiK5+aJMPHSeJiWOaAbMT Ekj++sOuSOf6ZRtL40TRcr68ZqRctc/1Cthp4yR7BZJQhHFyq+ZgFkPinrH59E+X I77OQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrheefgdduhedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkofhrggfgsedtqhertdertddtnecuhfhrohhmpegkihcujggr nhcuoeiiihdrhigrnhesshgvnhhtrdgtohhmqeenucggtffrrghtthgvrhhnpedtgffhtd etledtkeeihfefueeuhedvudfhvdeifeevtdektdetgfeiieejuefhtdenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeiiihdrhigrnhesshgvnh htrdgtohhm X-ME-Proxy: Feedback-ID: iccd040f4:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 9 Oct 2023 16:32:42 -0400 (EDT) From: Zi Yan To: Huang Ying , linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Zi Yan , Andrew Morton , "Matthew Wilcox (Oracle)" , David Hildenbrand , Baolin Wang Subject: [PATCH 0/1] Large folio migration fix and questions on migration stats Date: Mon, 9 Oct 2023 16:32:30 -0400 Message-ID: <20231009203231.1715845-1-zi.yan@sent.com> X-Mailer: git-send-email 2.42.0 Reply-To: Zi Yan MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Zi Yan I am adding support for >0 folio compaction and find the VM_BUG_ON(!list_empty(&cc->migratepages)) in compact_zone() can be triggered when a large folio is tried to be migrated, split, and its split base pages are not migrated. The fix is in patch 1. In the upstream tree, large folios can be migrated via move_pages() syscall and there is no VM_BUG_ON in do_move_pages_to_node() but pages left in the source page list will not be returned to LRU lists. This is from my code inspection and I have not reproduced it on upstream tree yet. In addition, I wonder if we need to add any large folio migration stats in addition to existing THP migration stats, at least for large folio split stats. Otherwise, large folio migrations seem to happen without any notice. Thanks. Zi Yan (1): mm/migrate: correct nr_failed in migrate_pages_sync() mm/migrate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --=20 2.42.0