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 E798EC30653 for ; Wed, 3 Jul 2024 20:08:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 277DA6B007B; Wed, 3 Jul 2024 16:08:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 227F16B0082; Wed, 3 Jul 2024 16:08:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0EFBD6B0083; Wed, 3 Jul 2024 16:08:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id E69A96B007B for ; Wed, 3 Jul 2024 16:08:49 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5168F1C1915 for ; Wed, 3 Jul 2024 20:08:49 +0000 (UTC) X-FDA: 82299529578.27.0B2CD2E Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf17.hostedemail.com (Postfix) with ESMTP id 63B9340013 for ; Wed, 3 Jul 2024 20:08:46 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="UoW7V4S/"; spf=pass (imf17.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720037294; 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=AuPx2MCb6YnDxtI1SJIPSsP+NVUqkPvcK23zUJ7cfuU=; b=XsW4jNLUXO+R36GHPNYi+NSL73JSs4eI65Om9Qyk8oQgoCZlNqYYFuo4ojtOiTSZPlVFB0 tdgbL1ov0gO3NrBOaVadwcAe0ixSIeq+9IPiNcObmb1CBPVu7LxHUkaiUMkCYJne4GrfT2 05r0ZUben0Kq1WahIMkaYrS39CC06pA= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="UoW7V4S/"; spf=pass (imf17.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720037294; a=rsa-sha256; cv=none; b=BvGmRzKHQOemmMcdBBdUyXCXOLX1LowybzpiTopOij5TInuWNaGmJgpvBHgPXm6StXwgiB zym9ynOs1BXAGQ7l3lM8z9ekMIkb46FlqOecawI7CGVdAPNfx4izOVRRnWg0Kp0zqd8jGM ZOtHTVOzDhGd5g6iWQTvSUUC3bd94O0= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 2420C61805; Wed, 3 Jul 2024 20:08:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 745B1C4AF0A; Wed, 3 Jul 2024 20:08:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1720037324; bh=/nseoorglFV3LVGoTmjXsLh5khxwk400OmG3i+R4mhM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=UoW7V4S/nCaVBYgHOxvfMlrMwvWOGPfTLT+WOrNnDWySJZyr7vx3w5NV04RWylcMV YuZFg17gdN6R3mN2irJOIoMeNNtPBPsKXAZKd7aM8GkhNr2hra/pYSaVGFjVG7jLKk Mk9FTPNWl9BM0shtiiooAW0jUQfWePyQWKfjGgL4= Date: Wed, 3 Jul 2024 13:08:43 -0700 From: Andrew Morton To: yangge1116@126.com Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, 21cnbao@gmail.com, david@redhat.com, baolin.wang@linux.alibaba.com, aneesh.kumar@linux.ibm.com, liuzixing@hygon.cn Subject: Re: [PATCH V3] mm/gup: Clear the LRU flag of a page before adding to LRU batch Message-Id: <20240703130843.ad421344a0f3f05564a7f706@linux-foundation.org> In-Reply-To: <1720008153-16035-1-git-send-email-yangge1116@126.com> References: <1720008153-16035-1-git-send-email-yangge1116@126.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 63B9340013 X-Stat-Signature: q6aprc9iok4hxuu76z4shbhf4k7aedeq X-Rspam-User: X-HE-Tag: 1720037326-131508 X-HE-Meta: U2FsdGVkX1/mDtwwFTo4aAoRBpKSwhVx0NHF7209wV0H9oErhrAj84mkNS61gQIwbT8/iQBuPRlahrUSBnomLGhq1yIjvzDNgCZEyEkq1ciz+lGdLVy0CRu297cBFwFS/vt4GOk4N9vcoRb9K1OYX1gSdCRkRJfTZ8CzCGcfxn7XEdjkMSXJwJ5ZDC/KCaUSnnWrj8jiL91/iMO+dsJPHBnsgLNTxWUiNpScEqswCLEQwmuSp8U1fM7BZ0pu6Z3se8xdk+HvCiowKMv/mSl7vs0z+8kOi53+UqA7KYcKVR4vfbIRb/k8vIP/RRA0JnXelAlXYiOa/t/H5a6vqmD2+LtHqENQskjo5/5H+mKjYlj0s1UaeyFMUYOtUOoXLYhlm5yEMlLjYywX3FRRkhWu7h/YbnMkBshGZDkNymUAUJaZYNsWVRKSVtl2QQmZgpD0K2mjPysTuJ31q+lNm84YSxShko9wijpr20IP27J8ZHa88vlsdJ6VdpnmAlDiVLQO5+Dc+LyL5tQ3fbd79ZiB6duPRdK0oHpjNqroo18kFmjctJ39wCMni5ruz8Zuz/huuZtr3IOmmDU9gclemX3sdTA2SmJQ9MSCXqcY5O4XrtpLZq9hTDGBTY/OnIWSVZAlfV+hpnZS6Y4eU5Y5YHq+xlg72kHVC+cdI8HCbOdQCQ+448emmzNQPerLKLEtcpdK22ZLYg8bboYneIRctHYjIQ7axJQDRsvI/GhEFsO9tzESECsuaQr7z8Fr3+wkWMjsmPKY7P9qDvcXfUwq0ZPwyYcNXzLGeisnGaTJlwEpt0KFDkUloYaz4872Lf0kFI4rAsWUjv475Xtx2VaH/pMXmlhvToUoQEIaxadpwlkHa24MQxAUVjYJcgVErX+HD6b5Rg79YNQp5sGqVTLgiX6Wqhmv//OPDCH3n5jQji+ttkSnI3aH5rYR3aLEAnUArgeBcufZAGFg+8k7aUjEx7w vcTcb1Fx ynxYXT+a5wmTk4cgerX5HQlcaUTpnf7L4LKI2YhNtZ3bWhZTa1f8OqMbuxEmNc1wkjYaK81nhn5DFbSWTTOf+2GhMPSaENuxqDtJpszp7gk9vqtr/mSU777g2F2as7RiEo99WFDOQ/htl5LZ/I+aqQzjDNlv5NO40I0994P5f+ZIdUz1B1/yVPg8iE0/BA7PtSiwMdRZRFWI97s7je/Qsr4BkEmr7eMUbNPWH1zGQqn5tOxUVlR/+jwiOUC9nvh+inMiQ8fnMphHTFXGt4/Gjdh8Zqw== 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: On Wed, 3 Jul 2024 20:02:33 +0800 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 with device passthrough, 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. > Thanks. I'll add this to the mm-hotfixes branch for additional testing. Please continue to work with David on the changelog enhancements. In mm-hotfixes I'd expect to send it to Linus next week. I could move it into mm-unstable (then mm-stable) for merging into 6.11-rc1. This is for additional testing time - it will still be backported into earlier kernels. We can do this with any patch.