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 0CA7CC54FB3 for ; Mon, 26 May 2025 09:34:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 69B506B0093; Mon, 26 May 2025 05:34:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 672D56B0095; Mon, 26 May 2025 05:34:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 561EE6B0096; Mon, 26 May 2025 05:34:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 36A026B0093 for ; Mon, 26 May 2025 05:34:56 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 7E1D4C081D for ; Mon, 26 May 2025 09:34:55 +0000 (UTC) X-FDA: 83484549750.04.7F7AF70 Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by imf02.hostedemail.com (Postfix) with ESMTP id 264F88000B for ; Mon, 26 May 2025 09:34:51 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=FpXYK1CO; spf=pass (imf02.hostedemail.com: domain of hyesoo.yu@samsung.com designates 203.254.224.25 as permitted sender) smtp.mailfrom=hyesoo.yu@samsung.com; dmarc=pass (policy=none) header.from=samsung.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748252093; 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=HfU5yKTJRJrorLMyEK6OCxNbQEUwn56XMrkE9AkHARE=; b=0ZwlP71D93HMcEpFhlUuRRiREUHyv1X/mesYc5/8Ug0xXHthBTbeNFxS2jUaMWAhxRVzgh wT0DN7612ggSA5AEqG4KLuLwb5ccO8TsldCCFHLTTxZF1RNUsGNron/g4sGROuVH+7ZsCw u22zkYNbv3BGkxOuVOdfGnNyaNCLvWo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748252093; a=rsa-sha256; cv=none; b=UKdoM8vp+8tkg/k/LdwkGdx4THdBJLwwTbQj/FtZ6eRjIIJJzyfCNr9XMwaGEE/U5vxja1 mhfWBTQnxF04WI9tUNa3lLpz12ImCnrUeSoZaMV+djigBersz6Gq5s60i9Hs81r3rBdGzK ZFO1ZaLyUQh4fK0BAgkL4Qu4Guw2tmk= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=FpXYK1CO; spf=pass (imf02.hostedemail.com: domain of hyesoo.yu@samsung.com designates 203.254.224.25 as permitted sender) smtp.mailfrom=hyesoo.yu@samsung.com; dmarc=pass (policy=none) header.from=samsung.com Received: from epcas2p3.samsung.com (unknown [182.195.41.55]) by mailout2.samsung.com (KnoxPortal) with ESMTP id 20250526093448epoutp021cab16e2f70309862f5679da12a4b950~DCgL_25531505115051epoutp020 for ; Mon, 26 May 2025 09:34:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout2.samsung.com 20250526093448epoutp021cab16e2f70309862f5679da12a4b950~DCgL_25531505115051epoutp020 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1748252088; bh=HfU5yKTJRJrorLMyEK6OCxNbQEUwn56XMrkE9AkHARE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=FpXYK1COQCF4N3GF8gEE5cg7HnWGgCH9JVg7v2EcBHPtLfuAJeaW5zKBIfKPcik2M THkB7HIvdvX4xxTYlPbajlHUNxq17GFMttK+qwz7NxcWDS5fgCS1lv2hs8sJ4XZ0By IRzRR9yxFN/EzjsW6sh/VLtqVO1a/I89VepZ5B7Y= Received: from epsnrtp02.localdomain (unknown [182.195.42.154]) by epcas2p2.samsung.com (KnoxPortal) with ESMTPS id 20250526093448epcas2p2a8d3597a950a9665517c5bd3701c5616~DCgLrYhzH2707027070epcas2p2c; Mon, 26 May 2025 09:34:48 +0000 (GMT) Received: from epcas2p3.samsung.com (unknown [182.195.36.98]) by epsnrtp02.localdomain (Postfix) with ESMTP id 4b5VwR2cf5z2SSKn; Mon, 26 May 2025 09:34:47 +0000 (GMT) Received: from epsmtrp2.samsung.com (unknown [182.195.40.14]) by epcas2p2.samsung.com (KnoxPortal) with ESMTPA id 20250526093446epcas2p250b069fc3983afe47640b769a9ff1265~DCgKa_RgB2708827088epcas2p2F; Mon, 26 May 2025 09:34:46 +0000 (GMT) Received: from epsmgms1p1new.samsung.com (unknown [182.195.42.41]) by epsmtrp2.samsung.com (KnoxPortal) with ESMTP id 20250526093446epsmtrp2bc7c398b9df691c9ade797b57e17590c~DCgKaMAof1349313493epsmtrp2b; Mon, 26 May 2025 09:34:46 +0000 (GMT) X-AuditID: b6c32a29-fda1d2400000223e-be-683435b650fa Received: from epsmtip1.samsung.com ( [182.195.34.30]) by epsmgms1p1new.samsung.com (Symantec Messaging Gateway) with SMTP id 57.FE.08766.6B534386; Mon, 26 May 2025 18:34:46 +0900 (KST) Received: from tiffany (unknown [10.229.95.142]) by epsmtip1.samsung.com (KnoxPortal) with ESMTPA id 20250526093446epsmtip1c2031ee5041985efb3a5ebc72c4157b5~DCgKQHyid1925019250epsmtip1i; Mon, 26 May 2025 09:34:46 +0000 (GMT) Date: Mon, 26 May 2025 18:33:00 +0900 From: Hyesoo Yu To: Zhaoyang Huang Cc: John Hubbard , jaewon31.kim@samsung.com, David Hildenbrand , "zhaoyang.huang@unisoc.com" , "surenb@google.com" , "Steve.Kang@unisoc.com" , Jaewon Kim , "linux-mm@kvack.org" , janghyuck.kim@samsung.com Subject: Re: reply: [RFC] pin_user_pages_fast failure count increased Message-ID: <20250526093258.GA3489925@tiffany> MIME-Version: 1.0 In-Reply-To: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42LZdlhJTnebqUmGwYoJyhZf1/9itph99heL RffmmYwWve9fMVlsnlNssfHpInaLe2v+s1os2NPPbDH50gI2i0ktPcwOXB47Z91l91iwqdRj 06dJ7B69ze/YPN7vu8rm0bdlFaPH4faz7AHsUVw2Kak5mWWpRfp2CVwZV5YuZSy4pVix/eM/ 5gbGt5JdjJwcEgImEl96n7OA2EICuxklTi3gh4hLSsz6fJIJwhaWuN9yhLWLkQuo5jGjxNZl HewgCRYBVYnr/YcYQWw2AXWJE1uWgdkiAjoSsx+sAGtgFvjEJDFxWT8bSEJYwFVi6RGIIl4B PYnLJ9ZBTf3CItHdfZ0FIiEocXLmEzCbGWjqn3mXmLsYOYBsaYnl/zggwvISzVtnM4PYnAKB EqcurWCbwCg4C0n3LCTdsxC6ZyHpXsDIsopRMrWgODc9t9iwwDAvtVyvODG3uDQvXS85P3cT IziatDR3MG5f9UHvECMTB+MhRgkOZiURXpk5BhlCvCmJlVWpRfnxRaU5qcWHGKU5WJTEecVf 9KYICaQnlqRmp6YWpBbBZJk4OKUamLb/MDr/2kJX0tRRW9P3aK/3m1X3lQ3+FPN8K28xmsOp zvrRyCFYfqP7jRf/Mq142w8eebyvNll1Kv99KfuCC92P4uweHl514oofa6zwFKY8jxjVp73M 79S+KZrsvfOkQnbu9QkVbgJyr0+uC1kvvuv8vzj25yG5zjkOHJrb1h447iqTMSHX+2bwVdb2 ULb1n7a/CBaucj/Bt2fanpVNNxYtVdz+4rav9eSQ2yuiCspZrs+/rBr+U+2M0tsopY8nZu/K KRbk//44r3NOxmd1tym1TLuCHrlsu3zC69CXwFsPVTcczAk5ot92WVj+kfFz/bTIII5lU+5/ XfHr8IEqW4FYmwXNwq0avpMvp7Bzv1ZiKc5INNRiLipOBABBcIjSFQMAAA== X-CMS-MailID: 20250526093446epcas2p250b069fc3983afe47640b769a9ff1265 X-Msg-Generator: CA Content-Type: multipart/mixed; boundary="----oRxFN-IW6TEbmBusn.EXIiq7I5yRwYOXOizBgewo77BvK4Z6=_bb783_" X-Sendblock-Type: AUTO_CONFIDENTIAL CMS-TYPE: 102P cpgsPolicy: CPGSC10-234,Y X-CFilter-Loop: Reflected X-CMS-RootMailID: 20250522130101epcas1p435244c12cfc9bb7895008b8ea98af064 References: <99ae448a-5c5e-4491-8cf7-1325f47e225e@redhat.com> <20250522130901epcms1p31d757b179fbb3563cad6bef4a1829235@epcms1p3> <20250522144418epcms1p2a31c1a5c95b1937077bddf1b30495e83@epcms1p2> <20250523023709epcms1p236d4f55b79adb9366ec1cf6d5792b06b@epcms1p2> <4e2305d6-b067-4963-b16a-367a254d22c1@nvidia.com> <20250526074845.GA2848800@tiffany> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 264F88000B X-Stat-Signature: b5r8rbtea9pq744pc7xrxekpeertxg5o X-Rspam-User: X-HE-Tag: 1748252091-451062 X-HE-Meta: U2FsdGVkX18gZdoQ+uuVZBra1moeZ+WBkf40EFBf/kH2QVtzkYGIS5X93rnigYNt3wD139ru2f8y+skJa7R5Hqsq5wSxWtBM/3ssdgFxhmeVu4m2YHHUQwTer7egYVtf1uBRlXIK+uCtnpXLQJM4Xz36TkRHIg1iQ9c7LDjgEXDRbU5JThzotChDoBUFmmxgP0r8OT9b6Kg3H8DZh/srOkEJ+9wrUwavM1kgt4CdsCXkn6gkb9CdsHGdW/YfIArs5EIie/bSxYYKIOvJBXbiLcZJYJBxJmXX18bXWtYeqZH4so6CaGJQs8v+RJPAaKYlXZ8DfnAN2+MYaBIzK9i+UnCfmORbwmgHyJHZ50eO4+Am1zhfG9eB3AtTGkvogiQ9KeAWSAmiMQSXoNV7mLcxUpJKOQMTwEeMB3Kmh5Ks5nxaeQwjG1McmPZsUHZn5IbtLJ6kGAsbyLTm7BMYmhZGGCYuMX07ABka3zo4FpbaE+sMS/BsSocxZs2jDGJ1TbVFQeQngirwTMF6O7Y8WvfxU7REbJ1WIGqsOEEY3w5jT4vDdeVLrkJb9emZJxrBBZe5W/qN90uB4nL6pObmLVp8z3N3OTE92r1hzrXRVKvjwJ8BIWFuxaZlfHH2NYib1Acx7mT2UaYcKZgT2Jb7gHivOKEr+n0aegIDReaZSt7XmXZwOz9UwzJSAcRveH8a9sN3P9tIn/a31K93Vo99om34DwwC02hryD1YHTSuHkAci7mxyZEbseoQCaortw54n3ICHr0kpJf7kw4nF8J+Lwt7xhSkEis+9CXM29kSm0KloiwO3NCaAkn+l5JXSdq5iafPyv670YwSOrWhiPpAqavKHoutg8sgNoLnV9b1bcDxKVxISfG/sY1TW5KMdCCh7Qzni6K8eBv5xmAUjlJR2E5QQqIu9XMvH8/NVxnkexIFFUCa5e0xrNZqLhRR5QRURCLKETVxIZCb6PNFfWwFi9V MgTMHmZZ yOsfhGr6WvcuVG0Z9cg1fh2r70L8RnPfJlZPA2Q97d4QDA5ClNiChpYumGdZNvGNP2Bk1DwFOZ4NHLF9czYTSa5lsO8SVmeMNIjMWmwy8cA0gCYmT2wpty7mUXCqx7KUGHYIJkaCPpnb/2EgiEComR4AcQBT9bFZYIhi5qLgDwI56geFgLixYmsLwFcoOxQxlBTE2MXwL/SWdDJmbW6x7jvYsI2wsjHNrJyyXwx0hUI+m6yrHS8D6wBAGRYDWzES4Mb7e/wWQ1VUGofMWbammtRGJsU2NxGFkc403VKZHINMIq//EWDsIItoVWfXoDQwTbRHv2xUouyIQCip9fIEdlmibUHBzOptb2ho1 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: ------oRxFN-IW6TEbmBusn.EXIiq7I5yRwYOXOizBgewo77BvK4Z6=_bb783_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Disposition: inline On Mon, May 26, 2025 at 04:05:16PM +0800, Zhaoyang Huang wrote: > On Mon, May 26, 2025 at 3:50 PM Hyesoo Yu wrote: > > > > On Thu, May 22, 2025 at 07:52:41PM -0700, John Hubbard wrote: > > > On 5/22/25 7:37 PM, 김재원 wrote: > > > ... > > > > I think this is what you meant, please let me know if you have an idea to make this nicer. > > > > We may be to able to prepare the patch next week. > > > > > > > > static long > > > > check_and_migrate_movable_pages_or_folios(struct pages_or_folios *pofs) > > > > { > > > > + bool any_unpinnable; > > > > LIST_HEAD(movable_folio_list); > > > > > > > > - collect_longterm_unpinnable_folios(&movable_folio_list, pofs); > > > > - if (list_empty(&movable_folio_list)) > > > > - return 0; > > > > + any_unpinnable = collect_longterm_unpinnable_folios(&movable_folio_list, pofs); > > > > + if (list_empty(&movable_folio_list)) { > > > > + if (any_unpinnable) > > > > + pofs_unpin(pofs); > > > > > > I think this is correct, although as I mentioned in the other thread, > > > that implies that commit 1aaf8c122918 (which didn't add nor remove > > > any pof unpinning) is probably not the true or only culprit, right? > > > > > > > + return any_unpinnable ? -EAGAIN : 0; > > > > > > Ha, the "?" operator almost always does more harm than good. > > > > > > Here, for example, it has obscured from you the fact that any_unpinnable > > > is being checked twice, when you could have merged those into a single "if". > > > > > > > Hello, > > > > I was wondering if the original problem - an infinite loop when pages allocated by > > cma_alloc() in vm_ops->fault are passed to GUP - still remains unresolved. > > (To be honest, I'm not quite sure how such pages end up being pinned via GUP. > > Is that the expected behavior, or could it possibly indicate a bug ?) > The original problem arises from applying CMA as guestOS's memory > slots for kvm which use GUP to setup its 2nd stage mapping(HVA->PFN). > You can check KVM code if you are interested. > Thanks for the kind explanation. While I'm not deeply familiar with KVM, my understanding is that there are cases where GUP is used on CMA. So does that mean pinning memory from the CMA was actually intended to succeed ? In other words, with the commit 1aaf8c122918, it seems that pinning the CMA and no LRU pages no longer results in an infinite loop and instead, the pinning is now allowed to proceed successfully. Was this the intended behavior ? I believe the pinning of CMA pages is something that should be properly handled, and I understand the proposed code above is also intended to address this issue. However if -EAGAIN is returned in cases where unpinnable pages are present, it seems the infinite loop problem could reappear. In general, we try to avoid pinning memory from CMA, so the fact that certain CMA regions can still be pinned seems contradictory to that principle. (folio_is_longterm_pinnable() function returns false for CMA.) Is there a way to distinguish between CMA regions that must not be pinned and those that might be allowed to be pinned like KVM ? > > Would it be make sense to try calling __lru_add_drain_all(false) in collect_longterm_unpinnable_folios ? > Please be noted that not all the pages allocated from vm_ops->fault > will be added to LRU. Yes, however, in our case, where the issue occurred due to pinning a cma page, I believe there was likely contention around lru_add_drain_all(). Thanks, Regards. > > We could consider limiting the number of -EAGAIN retries to a fixed count (e.g., 5 attempts) to > > avoid an infinite loop. Or perhaps in check_and_migrate_movable_pages_or_folio(), > > if the list is empty but any_unpinnable is true, we should consider returning an error > > instead of EAGAIN to explicitly prevent longterm pinning of CMA allocated memory. > > > > I'd be interested to hear what others think. > > > > Thanks, > > Hyesoo Yu. > > > > > > > > + } > > > > > > > > return migrate_longterm_unpinnable_folios(&movable_folio_list, pofs); > > > > } > > > thanks, > > > -- > > > John Hubbard > > > > > > > ------oRxFN-IW6TEbmBusn.EXIiq7I5yRwYOXOizBgewo77BvK4Z6=_bb783_ Content-Type: text/plain; charset="utf-8" ------oRxFN-IW6TEbmBusn.EXIiq7I5yRwYOXOizBgewo77BvK4Z6=_bb783_--