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 7CE24C30653 for ; Thu, 4 Jul 2024 06:24:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 070B46B00A0; Thu, 4 Jul 2024 02:24:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0210B6B00AE; Thu, 4 Jul 2024 02:24:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E517A6B00B0; Thu, 4 Jul 2024 02:24:28 -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 C83216B00A0 for ; Thu, 4 Jul 2024 02:24:28 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 46EA7A1062 for ; Thu, 4 Jul 2024 06:24:28 +0000 (UTC) X-FDA: 82301081016.18.A82AADF Received: from m16.mail.126.com (m16.mail.126.com [117.135.210.9]) by imf26.hostedemail.com (Postfix) with ESMTP id 710B9140003 for ; Thu, 4 Jul 2024 06:24:25 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=126.com header.s=s110527 header.b=BOfhcVi8; spf=pass (imf26.hostedemail.com: domain of yangge1116@126.com designates 117.135.210.9 as permitted sender) smtp.mailfrom=yangge1116@126.com; dmarc=pass (policy=none) header.from=126.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720074254; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/AKERoNUk3QOspjtoJsYJHGJH3MzhEmNn77tnVZjOls=; b=Z0/kICIGhl3xyJGnQaEN86sf26hWny2YDie6MX5I+P6hmCyhwXc5EAe3XavHoySLO4zoMu WDV7VmkAub3ioCRm09+mMWbRNKALwbBlUhTm+eNpZSmrCIaXSND8CN1NRY+kh0TCLnISec BzBHjVLYgtIYCDeHDZXOx9XspAFytoo= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=126.com header.s=s110527 header.b=BOfhcVi8; spf=pass (imf26.hostedemail.com: domain of yangge1116@126.com designates 117.135.210.9 as permitted sender) smtp.mailfrom=yangge1116@126.com; dmarc=pass (policy=none) header.from=126.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720074254; a=rsa-sha256; cv=none; b=rvkT9lCtKx51N9lWwH/WOTtgI25MslYy6yg9keOHFPMMcbcg23PjOuOVORJ7ID26kNMrfM pp5Jw9cX5xhhrIO2DT/P/s3v7TSAwDvonizyfY2xV0TA7/W7zQNDLYUn8VuO3Ls5ZD9Ec6 VAI41kLJbnpncVrXgR1/33gdKg7iCd0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Message-ID:Date:MIME-Version:Subject:From: Content-Type; bh=/AKERoNUk3QOspjtoJsYJHGJH3MzhEmNn77tnVZjOls=; b=BOfhcVi8iWK8aFiViJYt4G9BC6pASMp8AFGgf4Bp6m/VWeZu+8Dzp1sjCZYUpA 2UWjo+FI+O0h8TGOSchnGjmfY9YPLl3fxxoRDMTge7DTifnBkFhjegFd0eeAJib4 XOz8G0V3CNHrRWx68NDaHoMV/bQSrZ/a9JiKW9wxqOk84= Received: from [172.21.22.210] (unknown [118.242.3.34]) by gzga-smtp-mta-g0-2 (Coremail) with SMTP id _____wD3P+YOQIZm42A0AQ--.856S2; Thu, 04 Jul 2024 14:24:16 +0800 (CST) Message-ID: Date: Thu, 4 Jul 2024 14:24:14 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V2] mm/gup: Clear the LRU flag of a page before adding to LRU batch To: David Hildenbrand , akpm@linux-foundation.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, 21cnbao@gmail.com, baolin.wang@linux.alibaba.com, liuzixing@hygon.cn References: <1719038884-1903-1-git-send-email-yangge1116@126.com> <26efe5f2-0cad-404c-82ca-a556469ba9c7@redhat.com> From: Ge Yang In-Reply-To: <26efe5f2-0cad-404c-82ca-a556469ba9c7@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:_____wD3P+YOQIZm42A0AQ--.856S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxuF1rCryxAr4UuF45CF1xXwb_yoW5XryrpF Wft3WakrWDXFZa9rn7J3yDCr1SyrZ2yw45Ar1fJr18Cws8WFya9rW5K3WDWa45CrWYga1a vr409rn5uF4DZaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07j5WrXUUUUU= X-Originating-IP: [118.242.3.34] X-CM-SenderInfo: 51dqwwjhrrila6rslhhfrp/1tbiGBUSG2VLcMptdgAAsL X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 710B9140003 X-Stat-Signature: eymk5bm4stkcyaarnn8ds6zomqud49xh X-HE-Tag: 1720074265-562572 X-HE-Meta: U2FsdGVkX18JgHhBRdQcH+14qU+5mFHcTInAm1Wx+pkQdi7s5BiHEWons1xo0Hi490WZFWSC0Y1HqZQx5CHF8Xwt/VzBRO67V4dkDo9HSuSCRCiL3YNIjI65X5yz9iVwYW89eYrcewZaK3yopIXTZ7mRh0IygGXtzGgpJKIaS75135A8NJKTMTLfcD7J2bHR7LmY7E3upAWodlJmzH5P0kM5gZaid6lgvGzJ7eb1sRY4k4ngG41Jph3hJnZtqpNF1cL5BhMgU1g9XipPjkknzeZYZTa444yRd1pVRHr8QxBQ28Q4tPJ9LMvBXXwgO+H5CBzIlWfD+uAoitgBJQzLm2zBjID1en+6Bb4cLpkKxKU3SseBkva8eT9N/ZmmNMHmuJ7M/SPFC/KkzMVa2MrroJODJea2Yuq3GA8iCZXkkdiqFIurC2PmRz2+x6Ild9gG3ZbdR7m859PM5sNeJEFlQsWQpCHFKrixJjgCZeS/Znaj5E750pGLEVjc7HQ7937wQi2yFHX9rsHbohfJf0HM7Av5oxGQSISHbYUWG7/J21xoXXOf0wltChsmSCdB4+ssAEsLXSPUH45m4oT21fYrEuZqcso7rC7421tQjhucrQaHCYrGaeC0MhxjTZav/2EUEUN8zuO4I9CrXtZqb8TBn/mt4hj7XqyHAxyIYJamYFWyTlHEBJmxHk7vUCBAU4l4ph2fDWB0fvXP2viElIFGVJlCQomDg0AB0H7CXm77sBVpqVPHJpY9lBu7Wtz+w+SOyXoBKAGTuYWVOLff+jgCn2S+9N5xSGBYEtF9MVFSAR9/bXUIZbL+/Rz++dkz4Eo30AjIUC+iGZXzITuTDdamNtqRJuFdlC1aT4HkJ8KS87mHDFbMjwaK4BWfJ5I+RS/fOqsU4L/fvG+Smd4N6ZW8XkA1y25gAwNLk8ConkBwOvSb83nRTVMJAoFiQExPxPeSuv6c0PHlChBZjrKd2B7 Pr/W1eS/ kNH87WTQcdcUDTaummBMbhpx7rTPrUSPP7uyl8ew98jZCGvHCvRhmjRhIWkv8vH05e7XLjOKVR8R6emIein04rHLQQK6TuKKj0C0DHcMfPrCs4BOwqc2xsVsTvRSKsO/xuf4vbsFj6pw5vS5vwa02c2qZFTP07SxcFzMHuHEUHbcXQLyiPdu1OzdLTgxJJGO0kJGCQrhwic4RFQc+B8Tsv4Fx3huQcolz2wynsiIN5IE029kJgK42wF9UhN2vaLmIGL/d2y02+YMIV7Pqi2sVQLsRj0jFGLKx27nsCtBFWYrtH842KdtpDevOnI9lR4fABfdOZ5rgGbzbmopdVHeoEdgRELiOAQeajhLkqUDx5IuKFL4fhh3/eFZSOfkU2bvM2JTDaG5gkhBuYfmyxJr7ooTabQ3BzGwMuD7CeD/2/FDJ7uR/BRuHCc5+O4Ieapg9iqocPZh7vpUN1Q/KHfXKLKF6SChHDAV4HPqQQ9jeGSabsf4= 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: 在 2024/7/3 20:02, David Hildenbrand 写道: > On 22.06.24 08:48, yangge1116@126.com wrote: >> From: yangge >> >> If a large number of CMA memory are configured in system (for example, >> the >> CMA memory accounts for 50% of the system memory), starting a virtual >> virtual machine, it will call pin_user_pages_remote(..., FOLL_LONGTERM, >> ...) to pin memory.  Normally if a page is present and in CMA area, >> pin_user_pages_remote() will migrate the page from CMA area to non-CMA >> area because of FOLL_LONGTERM flag. But the current code will cause the >> migration failure due to unexpected page refcounts, and eventually cause >> the virtual machine fail to start. >> >> If a page is added in LRU batch, its refcount increases one, remove the >> page from LRU batch decreases one. Page migration requires the page is >> not >> referenced by others except page mapping. Before migrating a page, we >> should try to drain the page from LRU batch in case the page is in it, >> however, folio_test_lru() is not sufficient to tell whether the page is >> in LRU batch or not, if the page is in LRU batch, the migration will >> fail. >> >> To solve the problem above, we modify the logic of adding to LRU batch. >> Before adding a page to LRU batch, we clear the LRU flag of the page so >> that we can check whether the page is in LRU batch by >> folio_test_lru(page). >> Seems making the LRU flag of the page invisible a long time is no >> problem, >> because a new page is allocated from buddy and added to the lru batch, >> its LRU flag is also not visible for a long time. >> > > I think we need to describe the impact of this change in a better way. > This example here is certainly interesting, but if pages are new they > are also not candidate for immediate reclaim (tail of the LRU). > > The positive thing is that we can more reliably identify pages that are > on an LRU batch. > > Further, a page can now only be on exactly one LRU batch. > > But, as long as a page is on a LRU batch, we cannot isolate it, and we > cannot check if it's an LRU page. The latter can currently already > happen for a shorter time when moving LRU pages, and temporarily > clearing the flag. > > I shared some examples where we don't care, because we'd check for > additional folio references either way (and the one from the LRU batch). > > But I think we have to identify if there are any LRU folio/page checks > that could now be impacted "more". At least we should document it > properly to better understand the possible impact (do we maybe have to > flush more often?). > Thanks. I have reviewed a lot of paths using LRU folio/page checks and haven't seen more impact. I will documnt possible impact in next version, thanks.