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 8128DE7718B for ; Sat, 21 Dec 2024 16:18:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BAF3B6B007B; Sat, 21 Dec 2024 11:18:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B5F446B0083; Sat, 21 Dec 2024 11:18:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B1F36B0085; Sat, 21 Dec 2024 11:18:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 7DDD96B007B for ; Sat, 21 Dec 2024 11:18:32 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1724745972 for ; Sat, 21 Dec 2024 16:18:32 +0000 (UTC) X-FDA: 82919472636.06.1100016 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf26.hostedemail.com (Postfix) with ESMTP id 6992A140011 for ; Sat, 21 Dec 2024 16:18:02 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=fRF4K83E; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf26.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1734797893; 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=9zbL9DzfI/m+SVuvQfuz5ThQUFsMGBqPX/Gf47k6fXo=; b=kaWM2vvID1PGhqR/JjeKOdt1cv1YljWiymJrMU4/ABccO2+jqHjMLXtbgIro5jG4zXtSFF x9RXR5Vov29JXtle/1ksyKPYxiiX6ZwEs+Q90N70PGRA1COQw+QYEgfSCJfrr29vfwR2IC YdZmiU8EKedRSzyFzXn0YTZLX/QWqeE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734797893; a=rsa-sha256; cv=none; b=5okV/lLAL1TmogvQSMCE9kkj16bAgXCvATenbIQW8B0P81W1WvVYwi35mkKY4sVC8JIqjF y9wLcWAQSKbXgZPX6NdYO5ri0BSw8nv9ZovqdUYUp9c2hfgPnPol4tOS6YQCfI25vwZBce p0/hNtmHxd0KXZq5O789o8A7UeFPKeg= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=fRF4K83E; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf26.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1734797908; 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=9zbL9DzfI/m+SVuvQfuz5ThQUFsMGBqPX/Gf47k6fXo=; b=fRF4K83EZmx0EdjXCdNXqmfPfCr1PkT98Jk9nQNecEQRHi6xntDsFdnDO9H2q/pYfpvw0e 4QuptB+gSWUwWkU29biSqacwHhBbfOmhNbExiYqXHQMRH6e06xsfOcc3nJeTBZZ1qOG/Lk g72anT4dORufI7bxdoKpau2sH6jLzX8= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-556-1ZVu6U8RNN6oa4cCFqnmwA-1; Sat, 21 Dec 2024 11:18:25 -0500 X-MC-Unique: 1ZVu6U8RNN6oa4cCFqnmwA-1 X-Mimecast-MFC-AGG-ID: 1ZVu6U8RNN6oa4cCFqnmwA Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-436219070b4so14941355e9.1 for ; Sat, 21 Dec 2024 08:18:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734797904; x=1735402704; 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=9zbL9DzfI/m+SVuvQfuz5ThQUFsMGBqPX/Gf47k6fXo=; b=Lvt+Y3d3HZSJjUMZkOrL3ZMc9M+G8WpH9ta+z2WiK3BeqSnBgtegzvbqdjg/2sYW4L OyW6v/MVWFsqADdqrOVW7j1MuQ5U0I76jJAg80aspKrt3WQZruY8fyvH8nzMlJP5huj0 VFpkKFE3Wp2qxdOVCcdQaBBT8HpQkj28NSkGakwSPwy6V18Dqv560jGr8eVzKddb2lJ0 lVeJlq52ou9oVTpohHVGLbo9qAquOEVUiX4DlAcTsgNSlJyGkZX9I9/US6vxW5Be4fTu D9TKVWv7cz5nao0pcKp/Y3nBO4QZAZ9fz2gBCz6O8iVekxAapnPD2DudwKxmhz1Gk1Eu wppQ== X-Forwarded-Encrypted: i=1; AJvYcCUKlEO/YXSAWESNWPosJG1j3pS0h+qO5NtS5LMvkNn/NzOizsR1ezVsoQJNOS/0GWR2I5tWVLIVbw==@kvack.org X-Gm-Message-State: AOJu0Yyb3stLXCxdtRvEbtWJ/zrArUGpR/wf56wO9n6Ccx41jBA/FECK yk7BexLRhMoxRrAWbzekYJVbFxlDms4UQIBpimFkjg73Tq7P4tm1JZ9NThDOAj4G1mlIv5UpRx/ 5pXeO9ZvVwT3Fx9l6I9NYLqtWNcpqCzoRvVgub5uhaPZTmEzY X-Gm-Gg: ASbGnctnAIhJhPGnAo96wloSFciTeFtNkZGmHyF/zPx0mFX87A2ILlGMRDED5CgZZeW MiWuBkDdE9Htz1sBBGbquIlczY9aL7dWKcGmsJUjC9ZfHa3WMimTEm8uRirz8Wd4H1gDGW9cb0u j6IBPgfO7cGzeHl/xWn2aa5zuMi7QW4F71D52G3+DQJBl7lFhnj50+P8IerSH4I8i3kLY036kB8 jCG4wttsGoMIeEOkJ/EFmjwRhTtYiGKDI+4HXR8p/nBM7YvjG/R2SzGmb8a2PSP4loX30MWG9YK 09N3jI6bL+RP7i2PY3mp8CBZUXi0JEFZlqKcjKJfIFDkQ4K/vK7PfFrlLGKtnF6zj/l55wCOLJf teEM1BDWX X-Received: by 2002:a05:600c:314a:b0:434:f7e3:bfbd with SMTP id 5b1f17b1804b1-43668b49929mr53681365e9.23.1734797904459; Sat, 21 Dec 2024 08:18:24 -0800 (PST) X-Google-Smtp-Source: AGHT+IEdqCbMQ41u82OBsRy/1CcW1Fh9pEekW/Zl0oARY2fn4Zf97l2Ef5oung4fXnWxJt9AZi8inw== X-Received: by 2002:a05:600c:314a:b0:434:f7e3:bfbd with SMTP id 5b1f17b1804b1-43668b49929mr53681175e9.23.1734797903973; Sat, 21 Dec 2024 08:18:23 -0800 (PST) Received: from ?IPV6:2003:cb:c70e:d000:4622:73e7:6184:8f0d? (p200300cbc70ed000462273e761848f0d.dip0.t-ipconnect.de. [2003:cb:c70e:d000:4622:73e7:6184:8f0d]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a1c8332absm6718502f8f.38.2024.12.21.08.18.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 21 Dec 2024 08:18:22 -0800 (PST) Message-ID: <3f3c7254-7171-4987-bb1b-24c323e22a0f@redhat.com> Date: Sat, 21 Dec 2024 17:18:20 +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: Shakeel Butt Cc: Bernd Schubert , Joanne Koong , Zi Yan , miklos@szeredi.hu, 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: <968d3543-d8ac-4b5a-af8e-e6921311d5cf@redhat.com> <7b6b8143-d7a4-439f-ae35-a91055f9d62a@redhat.com> <2e13a67a-0bad-4795-9ac8-ee800b704cb6@fastmail.fm> <2bph7jx4hvhxpgp77shq2j7mo4xssobhqndw5v7hdvbn43jo2w@scqly5zby7bm> <71d7ac34-a5e5-4e59-802b-33d8a4256040@redhat.com> <9404aaa2-4fc2-4b8b-8f95-5604c54c162a@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: VOOdCXPSNDBsmLwm_Px8PIIK5JRYsLiaVhwXqhQ94_o_1734797904 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: prbgr9onxu1gh1am7h5qfa599ypi5jqd X-Rspamd-Queue-Id: 6992A140011 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1734797882-678792 X-HE-Meta: U2FsdGVkX1+juAlI8MxSgjODHmAdDj++dP1qHUpCik4m7L9MlsAj9OuGSlbSDnZxkSCwmIsOjqhhOlDPQV+rN2lFvOwIRVvEL8tEwd9PXlJQ9/z7eSIcGS710Tr6wuajVf6UNXQVf8iO8GFUJcSUNiOoF/a4RVSz/Lh1al6AZqOo9WTgGIGFHm5SPQpVcT5PRRjQhF9fwUp7eogW5Nb6hgznXgewXifR8USiQNwNDbRP7cb4+7FXKueG8QVhB3fi477Y8MudprHzZblkhcvS/nSdGgNe3WPPnCRjXLrGujfLM8Ntv0BXjnvv4lFbfRFB5U8PEicwZuyy3AUnehZI7VbSA6lCOzJ2/XUdInPAKv+nwiMjSty8NYCDbCBvn6yNB+u0w4a516gqr+mKXO3QZJnPwWkkdesy7IZdKsxXjYb0YOTw1kP8bTs3vCqbIBpMZdzhpSliqypfNw5l/sGRnzhEgeNVLh/64K9t0hCCrYq3M1RLiRMDPVCcjq2sOUXXPChmgNN892OzeKw5AotUJDOMrHbwgG49AQ6bVXROLelq8MNIhH5yzttmUy2qOND+Tblf+o1O4CvQ2HlQrv14BIpVg+fLnVf+uRddv1qwlo69Vwh5QhJGFUYaXVYy0UW3mAAkaCTfU25ltI4TY9UDXGpXtmsaBnteVuC0ubG34eRoy5owwB3veGp9fieLlLeIACnzrZhIJzwbm1HdTgDE6mt6XBGVOGDgGO64yHz3+9CLJxOsAF2P60bavKyyfIlsPzPzev3VJHPEoPrW742CM6xpZ9DFj1i/BOLaKMW+UnzR8in5q/tBrSUpR4U5wXLJDQ3GGO/Df8/B4FBnyW8ZuUuzxFHSEUEy50tCZf/IUGT6DR49dX0XAdQifsNMc7jNt8+dUJrn6ijLy52fv/k4Fk3wINPrBAzcBcdtEbk4E0SkfiYL1UlGALUJ8zGUTFwwcLmqyAgSPBxjcB20hyh t7U+I3kn 3/yl5h2k8ac8wXNLBM7La1s59xkfdZACPc6GUeE+KERj9oBVgLxw1Y0DFA1HPboX2CKwoWxsIZbY3IlCRjBoedOGiP+pxvYJkn9WoOP2XlmbUTfpvhIZpi8YQpuKPwOrg/ALcO/Z3guzOzif3s5rD8k48TYQBiBp2SGM/pj9f9vXW/8GdrTg35t9rQDm/OSacgzQbwN0tkJvtxFdn3ZWAscJJAC6I9ARCX7O8I6IUdPNQZiTHP2Qq5gnKs3tS+3EZiTE0eqejlXyDMKaHjGmz80xQ4SuDBH53xqH22YlYMV6UHAUNZzPMYnTBtNw7tuP3zLscIsgVWxnK2lmQ5HF50uxA0NcA9XbcCqun1lfBv1RaO84tWYVfHIafqENFemaGPJs8qMQyopObeJmKE3lOhi+ksqL0SdvyD/cLhyoAC50Y6EPnBX4gPfft+3T5igsPRFXK X-Bogosity: Ham, tests=bogofilter, spamicity=0.000113, 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 20.12.24 19:01, Shakeel Butt wrote: > On Fri, Dec 20, 2024 at 03:49:39PM +0100, David Hildenbrand wrote: >>>> I'm wondering if there would be a way to just "cancel" the writeback and >>>> mark the folio dirty again. That way it could be migrated, but not >>>> reclaimed. At least we could avoid the whole AS_WRITEBACK_INDETERMINATE >>>> thing. >>>> >>> >>> That is what I basically meant with short timeouts. Obviously it is not >>> that simple to cancel the request and to retry - it would add in quite >>> some complexity, if all the issues that arise can be solved at all. >> >> At least it would keep that out of core-mm. >> >> AS_WRITEBACK_INDETERMINATE really has weird smell to it ... we should try to >> improve such scenarios, not acknowledge and integrate them, then work around >> using timeouts that must be manually configured, and ca likely no be default >> enabled because it could hurt reasonable use cases :( > > Just to be clear AS_WRITEBACK_INDETERMINATE is being used in two core-mm > parts. First is reclaim and second is compaction/migration. For reclaim, > it is a must have as explained by Jingbo in [1] i.e. due to potential > self deadlock by fuse server. If I understand you correctly, the main > concern you have is its usage in the second case. Yes, so I can see fuse (1) Breaking memory reclaim (memory cannot get freed up) (2) Breaking page migration (memory cannot be migrated) Due to (1) we might experience bigger memory pressure in the system I guess. A handful of these pages don't really hurt, I have no idea how bad having many of these pages can be. But yes, inherently we cannot throw away the data as long as it is dirty without causing harm. (maybe we could move it to some other cache, like swap/zswap; but that smells like a big and complicated project) Due to (2) we turn pages that are supposed to be movable possibly for a long time unmovable. Even a *single* such page will mean that CMA allocations / memory unplug can start failing. We have similar situations with page pinning. With things like O_DIRECT, our assumption/experience so far is that it will only take a couple of seconds max, and retry loops are sufficient to handle it. That's why only long-term pinning ("indeterminate", e.g., vfio) migrate these pages out of ZONE_MOVABLE/MIGRATE_CMA areas in order to long-term pin them. The biggest concern I have is that timeouts, while likely reasonable it many scenarios, might not be desirable even for some sane workloads, and the default in all system will be "no timeout", letting the clueless admin of each and every system out there that might support fuse to make a decision. I might have misunderstood something, in which case I am very sorry, but we also don't want CMA allocations to start failing simply because a network connection is down for a couple of minutes such that a fuse daemon cannot make progress. > > The reason for adding AS_WRITEBACK_INDETERMINATE in the second case was > to avoid untrusted fuse server causing pain to unrelated jobs on the > machine (fuse folks please correct me if I am wrong here). Now we are > discussing how to better handle that scenario. > > I just wanted to point out that irrespective of that discussion, the > reclaim will have handle the potential recursive deadlock and thus will > be using AS_WRITEBACK_INDETERMINATE or something similar. Yes, I see no way to throw away dirty data without causing harm. Migration was kept working for now, although in a hacky fashion I admit. I do enjoy that "writeback" on the folio actually matches the reality now. I guess an alternative to "aborting writeback" would be to make fuse allow for migrating folios that are under writeback. I would assume that with fuse we have very good control over who is currently reading/writing that folio, and we could swap it out? Again, just an idea ... -- Cheers, David / dhildenb