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 C7C30C2BD09 for ; Fri, 12 Jul 2024 08:56:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3FAB06B0092; Fri, 12 Jul 2024 04:56:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 380D56B0096; Fri, 12 Jul 2024 04:56:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1FAA06B0098; Fri, 12 Jul 2024 04:56:30 -0400 (EDT) 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 035A16B0092 for ; Fri, 12 Jul 2024 04:56:29 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 823AD809BC for ; Fri, 12 Jul 2024 08:56:29 +0000 (UTC) X-FDA: 82330494498.04.6168792 Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by imf05.hostedemail.com (Postfix) with ESMTP id B2404100016 for ; Fri, 12 Jul 2024 08:56:27 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Mu1AsDT+; spf=pass (imf05.hostedemail.com: domain of hughd@google.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720774554; 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=ZKEGbykYk5TZAEolv3veio4AcHQ3n9AaxWALsKzF+q8=; b=b2gzJBbjBVcek3SCZlddi4BJMS6wa/BLrcwuxEgntLZu2ZLufcrEtg4LPIFa0DcBTie7Nm sT1SAkgkXrKMO4tyesOAPq4fRYmHPJusJK1a75gCsYuDdQvJnNZgJnGv+qVhtaQGYlehyg 9pt1xD2rHvOE45Wdm+Mt6cEQNkB+TR8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720774554; a=rsa-sha256; cv=none; b=Im9RruEF6DBcS6GS9ygW3lYYD58ZXmzD4Du7IhY1o+VHO34uceRPyyMvdH885dsbtKDYX/ PWzMv9huDuPWTpwNKDeCoAaVkbDQmhZK568P50qyNUgXfc4QyJ8VAjLrj/a+nd04JrMAM6 VIGhZRFVbOcLNRqa4YgkltygiNMypOc= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Mu1AsDT+; spf=pass (imf05.hostedemail.com: domain of hughd@google.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yb1-f177.google.com with SMTP id 3f1490d57ef6-e02b79c6f21so1835352276.2 for ; Fri, 12 Jul 2024 01:56:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1720774586; x=1721379386; darn=kvack.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=ZKEGbykYk5TZAEolv3veio4AcHQ3n9AaxWALsKzF+q8=; b=Mu1AsDT+uG0OPAQAhh4gXkndDJgiYlCImldwlIA8+PB9bd2JygFfsmBaVrc5T1aNgX 9Fnre9n5JzcwT38+/Y0ZPtyYqF6pFufa83c4SN+CnHXIUKPZQOOa39NMXciWP0l08UBk N60vEkBtCxHXMlfYeZvDoIfsMXY1pTpqzMPTEYVZ3e0QXyZZ4iIhurs2R7m22e207vwG xu4LEn9AlXSg0mjAu/EaCEYVxY5I8ZsHA51lGhzuMJ4KVz/C3CcbDIog6Tibt88Pzy1o gcaNyKsSErIERrMuqCAU49ncP72SrZcbBlF/+XRjuGvj7ZuEEIlHcetZ8cR5CNI4lIUD /v9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720774586; x=1721379386; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZKEGbykYk5TZAEolv3veio4AcHQ3n9AaxWALsKzF+q8=; b=oD7ukeuaMli0adjsdvAXm/emJ/py0d0uDIRvNguprXmNaxq3iZDtyX1nUVwBC5ERkF nb11eEPisMd8wdDXzNtBwlAC2n97zUKVhenndHXWZq3RB30eUCt1s4AUN4vxTu5iHzES dhyX6rJR5le0tPmHIsTK530ZFdLXm+nJHWWJIo33qHVAPgIy9UltZIATu+nOmV97KiQt fjTZR5fiQxdXjLxxfF31AnLiwFFbKZ9sQb46zGii41sxLHA/5zjJQU+QMPQ7ENB2w1g3 hSVcxgofjakKbFhuYn32rF6/I+8qERp8oyH26zlxzW1abFdDGIROT/TQcY1JGKyLznwJ +xxg== X-Forwarded-Encrypted: i=1; AJvYcCVRy7Q7YCpXidlgNZDCaJCW/r2rZhBkIeDorSfAFEvKaYihu7R6fh7JuiakEzgZuRdYP3FvdoEu551fGYDnjTbgK1Q= X-Gm-Message-State: AOJu0Ywu1I3PLymlspOTi9sUABC9QF962oDqf65Ym86pnYjwbxyJQGKV dzQsDAgaK4xQV1EA1/GLLo5DnC7ddcxaByunrUWyKfK2ioj+Zm/+PRFzbzMbJg== X-Google-Smtp-Source: AGHT+IG42qjdytaoa1iAmt27ZcGzYpIdyY5FTx+R68VeXp1fc8qPNJCDIUt/qzCmpk8baLbEnC/TSg== X-Received: by 2002:a81:8ac3:0:b0:646:5f95:9c7d with SMTP id 00721157ae682-658f01fda1bmr108621857b3.36.1720774586407; Fri, 12 Jul 2024 01:56:26 -0700 (PDT) Received: from darker.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id 00721157ae682-658e69d9dfcsm14260607b3.118.2024.07.12.01.56.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jul 2024 01:56:25 -0700 (PDT) Date: Fri, 12 Jul 2024 01:56:04 -0700 (PDT) From: Hugh Dickins To: Andrew Morton cc: yangge , linux-mm@kvack.org, linux-kernel@vger.kernel.org, 21cnbao@gmail.com, david@redhat.com, baolin.wang@linux.alibaba.com, aneesh.kumar@linux.ibm.com, liuzixing@hygon.cn, hughd@google.com Subject: Re: [PATCH V4] mm/gup: Clear the LRU flag of a page before adding to LRU batch In-Reply-To: <1720075944-27201-1-git-send-email-yangge1116@126.com> Message-ID: <503f0df7-91e8-07c1-c4a6-124cad9e65e7@google.com> References: <1720075944-27201-1-git-send-email-yangge1116@126.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: B2404100016 X-Stat-Signature: t6i9m47rpam1qs3yws7n8bobw5fgcbyq X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1720774587-673628 X-HE-Meta: U2FsdGVkX198ovPhV6DGRq/XPoJNsDUY/wQ4ins7+azNQlKHz4yecjiUbHxCoMRbf4gABeF/AvdEzfWqzKQCZ5C34WzDYAnTjxk0Y9556aMZFUvKXN91s8XnMJwcrK90Qr7lzClBBjnG3P3wNAx3Tx9X2Pu2t1LPO+SNPgvWQVC+/6EAc20HqdvbKYU1jvNmeBb5V0oTpILYdQDsNJuLe4UrWnddz0x23YdbCSbGBsBccVOq2wxk0E+Rjy3awxkvQYrYAFbQTBlHzOLT0bhipfi6+IDynKuV6eGWr0KywPcZmDALZoypIXA50uVbvix+KKQutvAQEUVT3zhfY5pWSxv1wj0uI2LKqe1GhAlUvU2IS4s6iFdyvYQ8qow8/6MgZUhiSr98RFHzqvIHJnBG+DlipC0c8fFZPg9rQqqvnVGSZD/9bDJ1jQNILJS6jF8oh69dNeA9xzikXbcOKuF9JfPrmnGuHoYjp+IJe/8/7RHa3hGFAnm5MPxor4F3l4PghrnKli8Dq89W5tI5VZHTuKI5nq6BnprcXhKVfMNMzczXdjQKXXa6DKKJOZys74iVKlp9X0/pj5h2uW3MCWFrWIdva5Ubao5qVAIOlkL5ZwdqqDcJJb5o/6DfFb6OiZk5HsRBRx7vKgWNDcAJjPuvBbmFWfYg9fOr2PeDQ2bCCwIf5IXM86AflfDtURunM8ZaROUd3ADYuQgYrpJ2KJcu7XEjD3GskDD9e62OBTPWbUcWpPj8HIY1Bn53RB2IYp1RYkCR2gTqLsXL8EyC+Dt+IZLZFXEAkXoVSbxZU69PL6pcozR7IJtLtG7j8U4SJULRC+cm36SmtAJDxHKC3j8iYIDVVhyYuj+7HDSafsfonNkkcqgl3adNc90A+rt850rvrxKPuCLIk7DwtGiLmdyPtIZnO7xHoOjoN5Qh05DcspFXXU6XAQbHGcHfKtlJCeELML5cod+LohAJjfT21hc gP0oPDpc Olkf5QGg73N1zQgt5sRvPSkTMt8x8JjeZfDUHtJx+iMVz90hP8L5o9te9SLSWTK/J8g/4NNr8Ktun0cBgnsISNS8edv4KZS67X3t27IAqng07jqKKvOW6UB9mGgrPX5FtmtxB+TqTToYjIH++RZThoMWx2BaXzqd8FrAlbTfxFCtEVM9mpuWqJpKT5m9nJBCVqULV0T9Vgnxw4VubLVd448xn9QLL1LXldQjGlS8wv98zcvmGfRybqr9vemd4EXPtK4ghTFwCl0MB/c319KsYtD2nxyB7e4W3gm6pSGZ+x6/Su86UWk4DaGmiFh7ELTXY5wqt3t7xftmQ4ww//8lrUPYe/FcXpwSs+fqAy5tRf5MZBGy7qRGlr1LP/55tR5j+LG0jfYkixdevug808MCS6sjl3tkWxruPIR01zE4F8qcXoRfcBbj/1NLGigFs7kJUooK5 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000377, 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 Thu, 4 Jul 2024, 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). > It's quite valuable, because likely we don't want to blindly drain the LRU > batch simply because there is some unexpected reference on a page, as > described above. > > This change makes the LRU flag of a page invisible for longer, which > may impact some programs. For example, as long as a page is on a LRU > batch, we cannot isolate it, and we cannot check if it's an LRU page. > Further, a page can now only be on exactly one LRU batch. This doesn't > seem to matter much, because a new page is allocated from buddy and > added to the lru batch, or be isolated, it's LRU flag may also be > invisible for a long time. > > Fixes: 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate pages allocated from CMA region") > Cc: > Signed-off-by: yangge This is an interesting patch, and may (but might not) be a very good one. I have no objection to it going forward to 6.11-rc, but I do object to the Cc stable, and its current placing in mm-hotfixes-unstable (if that means it's to be rushed into 6.10 final). This is a subtle change to PG_lru handling, altering how that has been managed since 5.11 (and before). I have not observed any ill effect from this patch, but I'm not at all confident in understanding its implications - though perhaps braver and quicker minds are confident. To judge by the commit message, it's entirely to suit the if (!folio_test_lru(folio) && drain_allow) { line in collect_longterm_unpinnable_folios(). And it is attractive to associate the PG_lru with the unraised refcount. But I worry that it may not be to the benefit of others: for example, page reclaim's isolate_lru_folios() will no longer be able to isolate folios on the LRU while they're on an fbatch. Which may be okay (in the dirty case, pageout() loses interest once it finds refcount raised, so nothing lost there), or might not be. It's good to try this, but please don't rush it in. Thanks, Hugh