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 7DA56C54EBD for ; Fri, 13 Jan 2023 02:43:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 00B908E0002; Thu, 12 Jan 2023 21:43:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EFEA68E0001; Thu, 12 Jan 2023 21:43:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DC5848E0002; Thu, 12 Jan 2023 21:43:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id CC9208E0001 for ; Thu, 12 Jan 2023 21:43:15 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 65A9C1A0402 for ; Fri, 13 Jan 2023 02:43:15 +0000 (UTC) X-FDA: 80348229150.28.C6CBC16 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf25.hostedemail.com (Postfix) with ESMTP id E8553A0006 for ; Fri, 13 Jan 2023 02:43:11 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ddPOs6px; spf=pass (imf25.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.65 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673577792; 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=R+Z4y03ZJC3m+RYkYXj6vaUrac1npgIyrCzJAJ+OdZU=; b=EDFwYA6gZjlPixYJ5YW17a9T/XyBD2mQjMtMD3HM3vWqryV4xCPViGw/KdBME3A20L+JBG 8cxfJEi6OIZZi3bcdyDN9LozaOAD4PP7/aDJJUzHfW40TU2yQf4OCfaSZkeA93JtJ2yleX CvILx7lQn3HbAciyH/q8962j8OVYgXg= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=ddPOs6px; spf=pass (imf25.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.65 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673577792; a=rsa-sha256; cv=none; b=oPfRHyhJMc9r4KoCTX6d8v+r79zoj4KftjJfLnOp9oeRL6kpVZSL/DhJyd14q8m48x/uoU tjuG6GtTkYlmvTJUfxIVSjcAWAEHfN45sXsvnPoy8oLY/yD0rDw0Veap8RdbVgMnHGR3Z3 5eyGa6Pmyvyy7g3DZqN63gFFv+H5jS0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673577792; x=1705113792; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=82l/muiOQvveS879TIb4UaFpqF9ucXSfsqtshd/sFx0=; b=ddPOs6pxUpTq3/RrUZV74PLIguNqBv143RjF33uvfCEog2BqGxOmhvXJ hAchaHcYQaQEEIeVeRNjAykOcN7MRyR37PL47YuGTwOgnN/ClGjN7PEWV sS3fLUDxxtipRS/5RJUZ2QuoojRUkJS07nRod4C/1ec1fu/ohzc2Nr6Ed VoRyZdqN6eRPp1a4fg6RqkIfm7hwbEH01D0y8Oa7zOi74Clv6wMDuDHMF z8VGHjfOtO+I+BQSQAW81202AjCgiCN5IMqWesEVGG54RT2kHpz0ETOyj 1cijZyXPi8NFltVw+r2UG28WAofNliOSyQY9blPH0tV6K4Ma6NPTCbhAr Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10588"; a="325955539" X-IronPort-AV: E=Sophos;i="5.97,212,1669104000"; d="scan'208";a="325955539" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2023 18:43:09 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10588"; a="903438148" X-IronPort-AV: E=Sophos;i="5.97,212,1669104000"; d="scan'208";a="903438148" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2023 18:43:06 -0800 From: "Huang, Ying" To: Mike Kravetz Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zi Yan , Yang Shi , Baolin Wang , Oscar Salvador , Matthew Wilcox , Bharata B Rao , Alistair Popple , haoxin Subject: Re: [PATCH -v2 0/9] migrate_pages(): batch TLB flushing In-Reply-To: (Mike Kravetz's message of "Thu, 12 Jan 2023 16:11:43 -0800") References: <20230110075327.590514-1-ying.huang@intel.com> <87a62oy5o9.fsf@yhuang6-desk2.ccr.corp.intel.com> <87ilhcrzkr.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Date: Fri, 13 Jan 2023 10:42:08 +0800 Message-ID: <87bkn3rw8v.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E8553A0006 X-Rspam-User: X-Stat-Signature: 6zcfgsqresms8oan5kzb6em5mz8mhqrf X-HE-Tag: 1673577791-190849 X-HE-Meta: U2FsdGVkX1+0GzIE/yfhSPMetlFtbxDigbRYYgjKe7cyW+YG5hy1MuiPlXXJU0/2ZGFwL+IqlyWWWZ5q3f2D12c9scMP5UVXgjEyMbv3sQvSWXtiMDgbko3O+vrI2XUMIG+qpszZpcRqqD6+4xX/CZrb68mc54L9q3ENAmhXKsnuaA7Z4SdKwj30HEvTzT2IZgUfETP+E6Cyy9rfWqQdd4JO119zzUKrE1YrO4hm551q1bvQQoOhQ3QNWryFuYw5vDtIEdksSuRGXu3ioSKElAuMEEXSZPmXLDzvJuvhCTACOKqiXZHoco74Fb0meXdzdnESQ6eOpjWvLGGtUzf+L0/OQ387MAHGaTY9/fOMMx8OsV/zgrYuVFioOrJXTD+WJITimsz6dhlng77Mi/2Wbxrw30nlyKFR13QvYdLg+Dq3ut0x/PoCQ74Ie5jPhbJYL0FrONfOxEzdSxuaQk9vJBsi/a5oqcT9wz0gkps93EAENyzCZHZPdPWxRR/gtUroGR9/WXFdnvjV2KDYX3Ynh2TDaLrzZlCHPTKLYnDdDpefg2k4rGCDN+UDkd0i5gtnhgPp4leeaLvdwCCyKh0vUbUNQyP+HbcenIvgo2kfT9K2+5oXUSLOtgdYMtr4MHwfKOlhK24FocQAcK9H9RzRmANGL1tKfjmL7LFrM37ickcn1IUSKTzhUOy548BltOU0QK8BCe05TEyuyoglDKOHlUxX7vGI1BE+fHxZBRwE0MuMvwm+mgNcjevFE5pWQiseh6mulHurRrY7gUFrldZ+eaYE8pXHhQZXoSvOI7ETTPuUgYNRdU45sNnowhgW6iV0/CiiBN8BIIjaDbwgmLUUOQxMkuKdf77gk6ypvZkhjqf5IGtQHLwSsm0Aw8B5qtYFxmR2ZQI1RYNf9nzGEA9/5BVJBtzMplWB 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: Mike Kravetz writes: > On 01/12/23 15:17, Huang, Ying wrote: >> Mike Kravetz writes: >> >> > On 01/12/23 08:09, Huang, Ying wrote: >> >> Hi, Mike, >> >> >> >> Mike Kravetz writes: >> >> >> >> > On 01/10/23 17:53, Mike Kravetz wrote: >> >> >> Just saw the following easily reproducible issue on next-20230110. Have not >> >> >> verified it is related to/caused by this series, but it looks suspicious. >> >> > >> >> > Verified this is caused by the series, >> >> > >> >> > 734cbddcfe72 migrate_pages: organize stats with struct migrate_pages_stats >> >> > to >> >> > 323b933ba062 migrate_pages: batch flushing TLB >> >> > >> >> > in linux-next. >> >> >> >> Thanks for reporting. >> >> >> >> I tried this yesterday (next-20230111), but failed to reproduce it. Can >> >> you share your kernel config? Is there any other setup needed? >> > >> > Config file is attached. >> >> Thanks! >> >> > Are you writing a REALLY big value to nr_hugepages? By REALLY big I >> > mean a value that is impossible to fulfill. This will result in >> > successful hugetlb allocations until __alloc_pages starts to fail. At >> > this point we will be stressing compaction/migration trying to find more >> > contiguous pages. >> > >> > Not sure if it matters, but I am running on a 2 node VM. The 2 nodes >> > may be important as the hugetlb allocation code will try a little harder >> > alternating between nodes that may perhaps stress compaction/migration >> > more. >> >> Tried again on a 2-node machine. Still cannot reproduce it. >> >> >> BTW: can you bisect to one specific commit which causes the bug in the >> >> series? >> > >> > I should have some time to isolate in the next day or so. > > Isolated to patch, > [PATCH -v2 4/9] migrate_pages: split unmap_and_move() to _unmap() and _move() > > Actually, recreated/isolated by just applying this series to v6.2-rc3 in an > effort to eliminate any possible noise in linux-next. > > Spent a little time looking at modifications made there, but nothing stood out. > Will investigate more as time allows. Thank you very much! That's really helpful. Checked that patch again, found that there's an issue about non-lru pages. Do you enable zram in your test system? Can you try the below debug patch on top of [PATCH -v2 4/9] migrate_pages: split unmap_and_move() to _unmap() and _move() The following patches in series need to be rebased for the below change. I will test with zram enabled too. Best Regards, Huang, Ying ---------------------------8<------------------------------------------------------ diff --git a/mm/migrate.c b/mm/migrate.c index 4c35c2a49574..7153d954b8a2 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -1187,10 +1187,13 @@ static int __migrate_folio_move(struct folio *src, struct folio *dst, int rc; int page_was_mapped = 0; struct anon_vma *anon_vma = NULL; + bool is_lru = !__PageMovable(&src->page); __migrate_folio_extract(dst, &page_was_mapped, &anon_vma); rc = move_to_new_folio(dst, src, mode); + if (!unlikely(is_lru)) + goto out_unlock_both; /* * When successful, push dst to LRU immediately: so that if it @@ -1211,6 +1214,7 @@ static int __migrate_folio_move(struct folio *src, struct folio *dst, remove_migration_ptes(src, rc == MIGRATEPAGE_SUCCESS ? dst : src, false); +out_unlock_both: folio_unlock(dst); /* Drop an anon_vma reference if we took one */ if (anon_vma)