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 EE367E7718F for ; Mon, 30 Dec 2024 12:53:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3B9B06B0088; Mon, 30 Dec 2024 07:53:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 34E9F6B0089; Mon, 30 Dec 2024 07:53:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 196726B008A; Mon, 30 Dec 2024 07:53:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id EAD516B0088 for ; Mon, 30 Dec 2024 07:52:59 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 3B0EEA188A for ; Mon, 30 Dec 2024 12:52:59 +0000 (UTC) X-FDA: 82951614816.29.8B2EDF1 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf15.hostedemail.com (Postfix) with ESMTP id 8FA3AA000C for ; Mon, 30 Dec 2024 12:51:33 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AMYvRZMW; spf=pass (imf15.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1735563155; 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=bYh/az7Mloqe5cRtt1kfYYOZg9/kylXZvrIUk5llXAg=; b=du6pjctGOQjRMzm4JNofalNXiIkEg+v7m2Ua1Xt2XfyhaltpMXoibnvxxWVsOGW4T+pH+g RHGjRjhpo+zbWIIpJNByZZQhPv/Dd/iPO6aPbXql4vMK46BicRmrT0CSrbYpWNlsru4I6+ zh6978+CUJC7MtfAaUkLnrSAVArSkLE= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=AMYvRZMW; spf=pass (imf15.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735563155; a=rsa-sha256; cv=none; b=fNzwyATDeTbfvGB/Zz7wMaLcx0OfgSkF3rviW/mbpoLKRl9jVUTteyH0P4bdczI3+BzNxe 45vf4K2wvCKsKr7HpgSVwge3wX883BVJZvgTFoDyjZZTZ7nVAE7tOVrfJ1+HaJnuYbvb4F +W6v9qGeu2YleIPLh8Kl6JXXZ+Mqfrs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1735563175; h=from:from: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:autocrypt:autocrypt; bh=bYh/az7Mloqe5cRtt1kfYYOZg9/kylXZvrIUk5llXAg=; b=AMYvRZMWP5ILNGYEk8bPRL7zjSYYR4hSXTDb0yWYyDLHBy+JEmyfXVYBueCkKcItAgjroC 7IKM7SjfAnDFxdGogSJdzfPw6gARWYHfpksbvfbymh5rrZpvA4mAGT+O/19/4Eu1PEeo0W g6HOyhYQ6AZFXmpLKyMI2NnInC+bddo= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-130-SsIQK0oTPUK81ELtA8FwKA-1; Mon, 30 Dec 2024 07:52:54 -0500 X-MC-Unique: SsIQK0oTPUK81ELtA8FwKA-1 X-Mimecast-MFC-AGG-ID: SsIQK0oTPUK81ELtA8FwKA Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-385d80576abso5896770f8f.3 for ; Mon, 30 Dec 2024 04:52:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735563173; x=1736167973; h=content-transfer-encoding:in-reply-to:organization:autocrypt :content-language:from:references:cc:to:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=bYh/az7Mloqe5cRtt1kfYYOZg9/kylXZvrIUk5llXAg=; b=Nro7ffXBVxhQ26IZxe1qC5ADbo2sGRp5WeTfDFBUR9ZfevsQqZlq+WUUwrtiXAwdmZ PIx9KEphEI9vq3ebqXjork/FsXz47rlUbQ3arOUg/lCCnhOGLkQsMwr7WG8BdXbvyr0U 0H78endfKGUUmuvJ9NnMHJTrvnAbHK8m54LbpR5/bpqLaxo/pNRLq50F1emzA1lf1Fml 3oDsBwhmLuJYVnfdLbEdhwOXfwSDUHwISGRsrZMEbopi6uGSy508Bp35klxTj9H8cHCL KvBpfcdvbfOjhKSusy/pr9m4FdK6rLCcu6bTi2MssOQT5rT6oSPg3NuhKKapr9bP7JCl KRBg== X-Forwarded-Encrypted: i=1; AJvYcCWLXEr0zZfCOnLbyEgqVVmpGI5GgJCLiaHk5AycnY/N7mQmJTnFuJ759APU8K2Fj1acLderd2K6iQ==@kvack.org X-Gm-Message-State: AOJu0YyWnnohsN+cFNg3FghYOrs139Mgx3a1M1TKZBb7NeDtS57vnMwJ 9xggu1is3t4l4NYrFafkR/o8+3OTm/odQlyzzIX6in43AD1aTrJ7laAANROdtB4IL+533wyt0R6 VFuY1m/8tFmJLic7uf+XRKcs54KNaGUglYmgmA35jD9pzAv7j X-Gm-Gg: ASbGncsz1nLfe2tZC7q7Al1E32UiJ6LK0G653QavoRc9ftdSU1J+AP54UJ8vdQxdM2Z UBlt9+Edx+CciLEmZqRp7me2TA7rm3a9hXRETQx4BC4zJT+eIKaTnW+OhWSZD30eOPKEQ3wi9Ev sClM0HwDF/X38NTm2TT1U3sRClAPWwNoQyGLxsDnZGYb0v/5BiWq7SUUTHv3rf9Bohk1dJTxO73 /wkE8bQyToSYPlx0B1qy3HuH5cJlVMdLu/T1N3srSO5gvk9vxsJwxY4r7mta/uUQReqhMxOUdxq Z4EC6n4Fetn1wtLA1b/NIJeXCrpH62mtzyEvjSq1PrZOXSGWe7er5ImwcfDYUI9Gw0IP5yLb5ic P78zUUWNN X-Received: by 2002:a5d:6d07:0:b0:386:3ba8:5326 with SMTP id ffacd0b85a97d-38a221f204dmr32428827f8f.21.1735563173351; Mon, 30 Dec 2024 04:52:53 -0800 (PST) X-Google-Smtp-Source: AGHT+IHzc8SpRKlr1APx0CLazzK9aHLUJLvxx8djaoMhJG2nB2YqMgBpEOOpbxmf/Dystqk+H5UHlg== X-Received: by 2002:a5d:6d07:0:b0:386:3ba8:5326 with SMTP id ffacd0b85a97d-38a221f204dmr32428795f8f.21.1735563172956; Mon, 30 Dec 2024 04:52:52 -0800 (PST) Received: from ?IPV6:2003:cb:c718:5800:c745:7e74:aa59:8dbe? (p200300cbc7185800c7457e74aa598dbe.dip0.t-ipconnect.de. [2003:cb:c718:5800:c745:7e74:aa59:8dbe]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4366127c493sm351880265e9.28.2024.12.30.04.52.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 Dec 2024 04:52:52 -0800 (PST) Message-ID: <8690de27-a1be-4440-a2d6-1a5cc56dcceb@redhat.com> Date: Mon, 30 Dec 2024 13:52:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: All MADV_FREE mTHPs are fully subjected to deferred_split_folio() To: Barry Song <21cnbao@gmail.com> Cc: Lance Yang , Linux-MM , Ryan Roberts , Baolin Wang , Andrew Morton References: <142a47b6-ac31-465c-917e-7b2e98fddb2f@redhat.com> From: David Hildenbrand Autocrypt: addr=david@redhat.com; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q 9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4 3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs 9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF 89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9 M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3 AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq 3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6 3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8 kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt WNyWQQ== Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: gsaJEZTbufQQOevRyVLcfVwRUFIP6VaaiWJnuLJ1v6Q_1735563173 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 8FA3AA000C X-Stat-Signature: rho6znwb1zmysc8b8ofpus5z3apnb7zb X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1735563093-57522 X-HE-Meta: U2FsdGVkX1+ayCLNHFNImIcQVMy0TC3IGRy0DeTIMS5wNCnvATBszQZBBOVrJoPwbXzCEvwFSZ0U5NmwvLN50gP3ssGAuJpWuPAYGMHAGIwDCu0iOvP3S9Uzes/1NN9Zs8YFvqDZ7CJBzR8O89BJZKJ6tGTYvpMKMRQV5T9bl60ZwROWRscL8crEhU6L7lCKVayoWfDIp15QcEkdkNc5em+0NUSIEcKf1Uk++y3xvi9aJye2Pb636GQ+tU7Fd4G5sTBmMwLQ+ZRBvAEH/zoE8fJrwLNuXJQYIF/nnPDnrLeBw8lJ6v+QySVz8knXjSXu4dLMo5VF7EXQHM6CJehGFlp79z3KDMgJmDL1WSNCp8075agG1qFMq8HXzkcrJsb1/QZAR5GP361Rn1sNUP1piKUzBNhvPr4u8XpvFwJxSmw544BlR7wvPFC7QnMawkiGEQAZlg4+XMbT/ky9aQY59qCnjGzyaWH1tSDTnQ9XCwq89MTJBjDrMwCcW5qEroVduJrhoMOfaV5K8Ss3usr2Hm/pGHBX7DXDZlWEH9D89H4EYfNJch2RFOUC+8PSeXhKS6hwCQ7SY2qjVk9o8sKsQOFwJT3fsKlR3i4usdJc8gk1oGJoEzQfAQxBPbX6TvUe3lf5ZjiLPw7Ok5+LQUnqoW6eICdqo8k8gI4FNbRPGe83ps9+/MDl9G4qTUWPaDrb/iKt5zKjh1W7zM9JeoOTk12d+J0aRRfiuge9ZBFfGlOPVRkiYJ+Q6GJV31tsTapswSPd0Q2OlbSBNfUo8L6fsHtB7lwWcN8NFZhGj5K8eRFgLE/s6VmFs0pHpJQkDc6Hsbuhv8k8rn/haJqv7MdATv7vsOaAS9agKXvS4HmbITlKDUCDOI7xb9szlb5oy5nA9GbqtvItxL1JV5t3kVoJ+OziRazcqBNdOUe6jGV3cSEoRxsiQpjJfcu65DA0iyGrV2XTPn7xLvpaQ1xQUCL xHM4XP8c Gh+T8pbbfNMVmDznopk77AEYANAXsrM484SnyVxvvDtszgSgd3j9Bx1rBCeGIm/JRndHyRvvLvlxkYQ4FZKQvKWshPIEL1qbbKEOfen0G385RjwQkAQ+sPV/Op71o4PQoqFRkBGC3gUBo4dIp06RafLS/y+KtjPUNfm3oS1dLmBiB/Myyx/vTK7GvlWP8kwK2h6oQrULeatOI0CIPQGtLCFpzPgnKCzNg/hQ874bKiTCVxr5hzDo0vxC7eL4QQmogITNlseKk5VTlbXy/Lq0ipU8Q3Vmr6ONyIp5VLS91ysVFAt44MOOiGISDaxlO6+pcv3t4UNLibIbFniB0sJPCK/1ellHE5zVczPvN/7M4j5jbP7bThZ7IezhbNBBJEssmoFP0R0BDIPnoskby8JnvUm7I9Cgl2xx6l8Of9XRpiimxoxEXRBbDCvhr8xifAGNODFemF1UBM4FFr37fStgqkd2g0YgI8xzPUlIaUWBzxdJ/m6wdf2CGn07G0824Og66whFV X-Bogosity: Ham, tests=bogofilter, spamicity=0.013010, 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 30.12.24 12:54, Barry Song wrote: > On Mon, Dec 30, 2024 at 10:48 PM David Hildenbrand wrote: >> >> On 30.12.24 03:14, Lance Yang wrote: >>> Hi Barry, >>> >>> On Mon, Dec 30, 2024 at 5:13 AM Barry Song <21cnbao@gmail.com> wrote: >>>> >>>> Hi Lance, >>>> >>>> Along with Ryan, David, Baolin, and anyone else who might be interested, >>>> >>>> We’ve noticed an unexpectedly high number of deferred splits. The root >>>> cause appears to be the changes introduced in commit dce7d10be4bbd3 >>>> ("mm/madvise: optimize lazyfreeing with mTHP in madvise_free"). Since >>>> that commit, split_folio is no longer called in mm/madvise.c. >> >> Hi, >> >> I assume you don't see "deferred splits" at all. You see that a folio >> was added to the deferred split queue to immediately be removed again as >> it gets freed. Correct? >> >>>> >>>> However, we are still performing deferred_split_folio for all >>>> MADV_FREE mTHPs, even for those that are fully aligned with mTHP. >>>> This happens because we execute a goto discard in >>>> try_to_unmap_one(), which eventually leads to >>>> folio_remove_rmap_pte() adding all folios to deferred_split when we >>>> scan the 1st pte in try_to_unmap_one(). >>>> >>>> discard: >>>> if (unlikely(folio_test_hugetlb(folio))) >>>> hugetlb_remove_rmap(folio); >>>> else >>>> folio_remove_rmap_pte(folio, subpage, vma); >> >> Yes, that's kind-of know: we neither do PTE batching during unmap for >> reclaim nor during unmap for migration. We should add that support. >> >> But note, just like I raised earlier in the context of similar to >> "improved partial-mapped logic in rmap code when batching", we are >> primarily only pleasing counters here. >> >> See below on concurrent shrinker. >> >>>> >>>> This could lead to a race condition with shrinker - deferred_split_scan(). >>>> The shrinker might call folio_try_get(folio), and while we are scanning >>>> the second PTE of this folio in try_to_unmap_one(), the entire mTHP >>>> could be transitioned back to swap-backed because the reference count >>>> is incremented. >>>> >>>> /* >>>> * The only page refs must be one from isolation >>>> * plus the rmap(s) (dropped by discard:). >>>> */ >>>> if (ref_count == 1 + map_count && >>>> (!folio_test_dirty(folio) || >>>> ... >>>> (vma->vm_flags & VM_DROPPABLE))) { >>>> dec_mm_counter(mm, MM_ANONPAGES); >>>> goto discard; >>>> } >> >> >> Reclaim code holds an additional folio reference and has the folio >> locked. So I don't think this race can really happen in the way you >> think it could? Please feel free to correct me if I am wrong. > > try_to_unmap_one will only execute "goto discard" and remove the rmap if > ref_count == 1 + map_count. An additional ref_count + 1 from the shrinker > can invalidate this condition, leading to the restoration of the PTE and setting > the folio as swap-backed. > > /* > * The only page refs must be one from isolation > * plus the rmap(s) (dropped by discard:). > */ > if (ref_count == 1 + map_count && > (!folio_test_dirty(folio) || > /* > * Unlike MADV_FREE mappings, VM_DROPPABLE > * ones can be dropped even if they've > * been dirtied. > */ > (vma->vm_flags & VM_DROPPABLE))) { > dec_mm_counter(mm, MM_ANONPAGES); > goto discard; > } > > /* > * If the folio was redirtied, it cannot be > * discarded. Remap the page to page table. > */ > set_pte_at(mm, address, pvmw.pte, pteval); > /* > * Unlike MADV_FREE mappings, VM_DROPPABLE ones > * never get swap backed on failure to drop. > */ > if (!(vma->vm_flags & VM_DROPPABLE)) > folio_set_swapbacked(folio); > goto walk_abort; Ah, that's what you mean. Yes, but the shrinker behaves mostly like just any other speculative reference. So we're not actually handling speculative references here correctly, so this issue is not completely shrinker-specific. Maybe, we should be doing something like this? /* * Unlike MADV_FREE mappings, VM_DROPPABLE ones can be dropped even if * they've been dirtied. */ if (folio_test_dirty(folio) && !(vma->vm_flags & VM_DROPPABLE)) { /* * redirtied either using the page table or a previously * obtained GUP reference. */ set_pte_at(mm, address, pvmw.pte, pteval); folio_set_swapbacked(folio); goto walk_abort; } else if (ref_count != 1 + map_count) { /* * Additional reference. Could be a GUP reference or any * speculative reference. GUP users must mark the folio dirty if * there was a modification. This folio cannot be reclaimed * right now either way, so act just like nothing happened. * We'll come back here later and detect if the folio was * dirtied when the additional reference is gone. */ set_pte_at(mm, address, pvmw.pte, pteval); goto walk_abort; } goto discard; Probably cleaning up goto labels. -- Cheers, David / dhildenb