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 7E0ABE77188 for ; Fri, 10 Jan 2025 21:13:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 09EB86B00B3; Fri, 10 Jan 2025 16:13:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 050486B00B4; Fri, 10 Jan 2025 16:13:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D6E496B00B5; Fri, 10 Jan 2025 16:13:27 -0500 (EST) 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 AB55C6B00B3 for ; Fri, 10 Jan 2025 16:13:27 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 35C01B042E for ; Fri, 10 Jan 2025 21:13:27 +0000 (UTC) X-FDA: 82992793254.28.6ECED8A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf09.hostedemail.com (Postfix) with ESMTP id A32AD140017 for ; Fri, 10 Jan 2025 21:13:24 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=A1tdYsJS; spf=pass (imf09.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=1736543604; 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=EeIUoIjZUFNtiNRnVwaW4fp2T66i1qr7WJzeNybd0b4=; b=tbaVVrL4XEcD4q+y7b7OxkABCkU2R88y5hhJGldKqMy+padRH7elDyT9/RTAi+oILhUFlo sRx8kLPD2gfr+xepAlBFHQrjcaS5YGPxAe+Z9SlfrC1gx7N3kzHp1XbXUlbigVj+XaQUhy 4Nh6Lr+TNLwiu6ovNipObtGxA8Ioqb0= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=A1tdYsJS; spf=pass (imf09.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=1736543604; a=rsa-sha256; cv=none; b=M5AcSjnUgHqU7u71/C1FJMPxA8mdb7kNIwGpzuelawlSsP8p8cKOwpeRsm3i94FPlqcRpR N3JxeMcMRg8l6LLkhMgMGDz3XBTbLp4d3W2ClqnsL89z8O9OUMYZAaWO9Q1ViHyBoHfUbl zb+3wT/aO0eoHazWpCCFtsgyUEijx0I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736543604; 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=EeIUoIjZUFNtiNRnVwaW4fp2T66i1qr7WJzeNybd0b4=; b=A1tdYsJSigT7pSQxlNq8rHOVixQ60wcV0OLmG0J8EIIJr6PEmSDDxq7PsfCV+N1c3T/O25 5kTma51uFTO2JVKeb4ngyWgK749JJ4wX1+r32gSkVrR5yAvTQxDxztNvI7eM+Hbz8dOU1x MGiiq2ZewFn28I72rafCL9DSbVWWTB8= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-338-EwUSMpDGO6Gz7l-Tp6wLzg-1; Fri, 10 Jan 2025 16:13:22 -0500 X-MC-Unique: EwUSMpDGO6Gz7l-Tp6wLzg-1 X-Mimecast-MFC-AGG-ID: EwUSMpDGO6Gz7l-Tp6wLzg Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-3862b364578so1651863f8f.1 for ; Fri, 10 Jan 2025 13:13:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736543601; x=1737148401; 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=EeIUoIjZUFNtiNRnVwaW4fp2T66i1qr7WJzeNybd0b4=; b=EX98ZtbxIyMHdh/LPk5tr7aEyXuZNJU+GsYavihAgfVrFeu+Has0mRieT34ENfg8BY hvRZUSukLSq/XUHtC1yEVrScugzcSPuYyA1nJiJFZr+woqexEFVlrmxMeEb5pyhq7fgK GbpjwKZ2zeK8RpG72oegFLOGma8L3/Aa823II58QK5rjepnQxttmZVlKp3rS/2TmBfwY mXQr4A2ZJTebJEWnwPX617hbztIpjgBbCwwz8QEvfD9AtUpjZS7zClnGTOMLDMBiVZqK mXpKDf9t3ljjIRTO2DKJZp2WuXH1KEyDfW6dSP2rsFwu/SBzQc6PI2DKNJzi2VeF6Vl2 jS1Q== X-Forwarded-Encrypted: i=1; AJvYcCW5OPffHo/xnanJ69CL57vV8XHe6defZeCqXo9mbB42tRP5H231eWZh2Ul7YAZs2i6eeZhivP1ZHA==@kvack.org X-Gm-Message-State: AOJu0YyXnjuR5eav0w95O1487ZQnEAzGL4aXqAZRRpvLshDIXQ5nFX3w XWlz+O98q3LLg31ENB51bRsncvZETv2an7EHhPUJVLKsBtR8IY8LTJi3/KTQxxJrCooaSx7BYKe CNbakVPbx92Za8E22hutfT36KQen1MVoz67bcnM2Aj94xcYmp X-Gm-Gg: ASbGncue1V6VQ3gdVgcgw/+rKrdYRQmfi0MsTGNm0sqvlN5ANlE2UtrYHndImn3H9yU tK72IF+VqZ0ydJ8CBKKsfU/oliKskQOARQSp//4pXE5ZxwrJ5r23D+NB/h9bkA8ODideoyKw/r5 RUcRxMPDTvf8p+cnRavjwdEu3AgUo/iPJe4zvTXjAMHV6UuTjPAZ6wA65QEvZPntZxeBt4BYool KrvXKQePIQSu7yQSoPTTIId+vxGaAyhEaQCCyc9VS67ZgY5CnAlrCA3muCgsr506a5D9EV5EhKW jdr4sbv4LAkg6MqUghD8vQ07O3EuPef8+jujiBn+6CAY0mJZKk8LyVDPy66CyJYaqRsXW++z/oC BlK1lC/Zz X-Received: by 2002:a5d:6d04:0:b0:385:f07a:f4cb with SMTP id ffacd0b85a97d-38a8b0d3166mr6945475f8f.8.1736543600970; Fri, 10 Jan 2025 13:13:20 -0800 (PST) X-Google-Smtp-Source: AGHT+IG5R47FaOgB1kt8eBsOyKxn/mdF0lH6hJkFFQSVsNWL9a3o0cjUcVhjjK+cWeMmdXpZSiAiEQ== X-Received: by 2002:a5d:6d04:0:b0:385:f07a:f4cb with SMTP id ffacd0b85a97d-38a8b0d3166mr6945458f8f.8.1736543600591; Fri, 10 Jan 2025 13:13:20 -0800 (PST) Received: from ?IPV6:2003:cb:c708:e100:4f41:ff29:a59f:8c7a? (p200300cbc708e1004f41ff29a59f8c7a.dip0.t-ipconnect.de. [2003:cb:c708:e100:4f41:ff29:a59f:8c7a]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a8e37d01dsm5427873f8f.9.2025.01.10.13.13.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jan 2025 13:13:19 -0800 (PST) Message-ID: Date: Fri, 10 Jan 2025 22:13:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 4/5] mm/migrate: skip migrating folios under writeback with AS_WRITEBACK_INDETERMINATE mappings To: Jeff Layton , Shakeel Butt Cc: Miklos Szeredi , Joanne Koong , Bernd Schubert , Zi Yan , linux-fsdevel@vger.kernel.org, jefflexu@linux.alibaba.com, josef@toxicpanda.com, linux-mm@kvack.org, kernel-team@meta.com, Matthew Wilcox , Oscar Salvador , Michal Hocko References: <0ed5241e-10af-43ee-baaf-87a5b4dc9694@redhat.com> <446704ab-434e-45ac-a062-45fef78815e4@redhat.com> <791d4056-cac1-4477-a8e3-3a2392ed34db@redhat.com> <1fdc9d50-584c-45f4-9acd-3041d0b4b804@redhat.com> <54ebdef4205781d3351e4a38e5551046482dbba0.camel@kernel.org> 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: <54ebdef4205781d3351e4a38e5551046482dbba0.camel@kernel.org> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: UnF8zyfcn0Ac3-xtNsr9_P5-WlVmHajwTBchWo_aBIw_1736543601 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: A32AD140017 X-Stat-Signature: z5fkgamc7up734ktc5nfmh15ggnme6j8 X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1736543604-187584 X-HE-Meta: U2FsdGVkX1/yGzpO8cNI1bsJVXBnbmTPxrfsOtsjJnfMq4Ypra5Y7OnE9uF8gbkbuWuXwt6lF9ZHjmOEAD/uuNYU+0nASeSEpZUv62ugZfQ3mrQyCqpa5D+ABz7wDGJNcpVbjlFbtQi1u9A4ycPYqfqpYjcZ5PDi8dw9eJYLjyQqDuFEDUR9KSQiuFHxnocTGz2VTCuhGrersqsaga2z7lPetw3RXynjMQrYlHXTtvt/MDfiXh0ymDWsJxyz+pC04nUSQBSKf8sNGtNMrogZiXrfenIsCvs2AIbNTrh/GjpMoGjc/NrL6Po8/bRT4JObHO1Gy1DTzkWCUJ9bTEXqiqunGdxWoYRKSLQrwO+Vr1MU/PL4Fk9qx7jZFGYs9QVggbihtiiGIEhPTCMoA8UmN6+5sXWdRnbtBbIwR1ak23jLiranXQCIQNv35YOsOgTvzW7dcn/pvB+Y50SUz1lwQIeAeSM1PMk6lF1DDHAa+DpTRyESN0RamBjLRafJLeK6qxxGOlPKRobz3FTadbS80+ey+R4l/9RrQ2+JCrCtrzv24QMLAr4HqK46PjR4j3nj2uxoDzvMjcf9lSn2Npuou8Y3QzAZw1JN5Wu6I17S0aFKbpgpB0ScrkwoRFsEcBeOjzfKn3pIWyfYddacZghv+tahf5Imaoh0ZOh/dQH5G8uRwW06tZzV7/jT8hMGHIgKz4NcVgu+c9DRy1yiLTXaz3k/thnZpPoG1a/fizgnJtcX/yw9RO9msyIH2Pwl3iSzAqVyu5lxe5frhWx7FlneSD8U7kpyN7In5WjDFWUaJFJKcoxwkRO9X1lnPQLf+LOte+x/KOGYKLrmNzluOsdMqJdlIj5pVZ+PH2W/5xW7UFD9oDMNqDxGtJ5PLQpD531ivQKOpxAUiaWudM1RAVv6nixAwUrBk/GKJcHDN/P5fWQWKyh/GfF8/7NoD0AD4+gVpRDiHUv1nRx3ZeJLHNZ syHkfi7g 9J/vS+Ub1ViwambiDHYntCkMcxVj9H3MX74ufdr4heW2pI68e9brxHEPbg0RgoHu/hH3MBLlRrMCHsrFSQeMgzD3+w9PmtpVoXQ3LKxXYMmfiBUXxCyHeIdZcJNEo44ji+ussSJPaBvu/Fl4ILTJaQlXkqXUkzkz/UAGwBjNqfHvWwIRmWZeBuuxZL+10SXfzJNat+AieDThX4ozgzxc4A8lnQGuLXiT9J1DW9uG1GuHb9nTHybU36qaupX1lvw5na7ggKk2pCBZ+TZp+5ELMAbzB6O7T1pknFfK1hsghHuFowuEQJbJ8FntNareGXMQsQr47hfgfXFkTXg4ThFPcuAHz56lQlKsx4dYGKXZ79vPgRDXqRMAoz9E8By5L4BmIKXKpochAttV+3/rWqXrRGxH6SPhoc4iqlz/tZrF3QeGjWXvuiST7bLj7bFjkWdGbK4Tub3Ojrq80KRNON+W9W7iFUg== 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 10.01.25 21:28, Jeff Layton wrote: > On Thu, 2025-01-09 at 12:22 +0100, David Hildenbrand wrote: >> On 07.01.25 19:07, Shakeel Butt wrote: >>> On Tue, Jan 07, 2025 at 09:34:49AM +0100, David Hildenbrand wrote: >>>> On 06.01.25 19:17, Shakeel Butt wrote: >>>>> On Mon, Jan 06, 2025 at 11:19:42AM +0100, Miklos Szeredi wrote: >>>>>> On Fri, 3 Jan 2025 at 21:31, David Hildenbrand wrote: >>>>>>> In any case, having movable pages be turned unmovable due to persistent >>>>>>> writaback is something that must be fixed, not worked around. Likely a >>>>>>> good topic for LSF/MM. >>>>>> >>>>>> Yes, this seems a good cross fs-mm topic. >>>>>> >>>>>> So the issue discussed here is that movable pages used for fuse >>>>>> page-cache cause a problems when memory needs to be compacted. The >>>>>> problem is either that >>>>>> >>>>>> - the page is skipped, leaving the physical memory block unmovable >>>>>> >>>>>> - the compaction is blocked for an unbounded time >>>>>> >>>>>> While the new AS_WRITEBACK_INDETERMINATE could potentially make things >>>>>> worse, the same thing happens on readahead, since the new page can be >>>>>> locked for an indeterminate amount of time, which can also block >>>>>> compaction, right? >>>> >>>> Yes, as memory hotplug + virtio-mem maintainer my bigger concern is these >>>> pages residing in ZONE_MOVABLE / MIGRATE_CMA areas where there *must not be >>>> unmovable pages ever*. Not triggered by an untrusted source, not triggered >>>> by an trusted source. >>>> >>>> It's a violation of core-mm principles. >>> >>> The "must not be unmovable pages ever" is a very strong statement and we >>> are violating it today and will keep violating it in future. Any >>> page/folio under lock or writeback or have reference taken or have been >>> isolated from their LRU is unmovable (most of the time for small period >>> of time). >> >> ^ this: "small period of time" is what I meant. >> >> Most of these things are known to not be problematic: retrying a couple >> of times makes it work, that's why migration keeps retrying. >> >> Again, as an example, we allow short-term O_DIRECT but disallow >> long-term page pinning. I think there were concerns at some point if >> O_DIRECT might also be problematic (I/O might take a while), but so far >> it was not a problem in practice that would make CMA allocations easily >> fail. >> >> vmsplice() is a known problem, because it behaves like O_DIRECT but >> actually triggers long-term pinning; IIRC David Howells has this on his >> todo list to fix. [I recall that seccomp disallows vmsplice by default >> right now] >> >> These operations are being done all over the place in kernel. >>> Miklos gave an example of readahead. >> >> I assume you mean "unmovable for a short time", correct, or can you >> point me at that specific example; I think I missed that. >> >>> The per-CPU LRU caches are another >>> case where folios can get stuck for long period of time. >> >> Which is why memory offlining disables the lru cache. See >> lru_cache_disable(). Other users that care about that drain the LRU on >> all cpus. >> >>> Reclaim and >>> compaction can isolate a lot of folios that they need to have >>> too_many_isolated() checks. So, "must not be unmovable pages ever" is >>> impractical. >> >> "must only be short-term unmovable", better? >> > > Still a little ambiguous. > > How short is "short-term"? Are we talking milliseconds or minutes? Usually a couple of seconds, max. For memory offlining, slightly longer times are acceptable; other things (in particular compaction or CMA allocations) will give up much faster. > > Imposing a hard timeout on writeback requests to unprivileged FUSE > servers might give us a better guarantee of forward-progress, but it > would probably have to be on the order of at least a minute or so to be > workable. Yes, and that might already be a bit too much, especially if stuck on waiting for folio writeback ... so ideally we could find a way to migrate these folios that are under writeback and it's not your ordinary disk driver that responds rather quickly. Right now we do it via these temp pages, and I can see how that's undesirable. For NFS etc. we probably never ran into this, because it's all used in fairly well managed environments and, well, I assume NFS easily outdates CMA and ZONE_MOVABLE :) > >>> >>> The point is that, yes we should aim to improve things but in iterations >>> and "must not be unmovable pages ever" is not something we can achieve >>> in one step. >> >> I agree with the "improve things in iterations", but as >> AS_WRITEBACK_INDETERMINATE has the FOLL_LONGTERM smell to it, I think we >> are making things worse. >> >> And as this discussion has been going on for too long, to summarize my >> point: there exist conditions where pages are short-term unmovable, and >> possibly some to be fixed that turn pages long-term unmovable (e.g., >> vmsplice); that does not mean that we can freely add new conditions that >> turn movable pages unmovable long-term or even forever. >> >> Again, this might be a good LSF/MM topic. If I would have the capacity I >> would suggest a topic around which things are know to cause pages to be >> short-term or long-term unmovable/unsplittable, and which can be >> handled, which not. Maybe I'll find the time to propose that as a topic. >> > > > This does sound like great LSF/MM fodder! I predict that this session > will run long! ;) Heh, fully agreed! :) -- Cheers, David / dhildenb