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 127BBC04FFE for ; Wed, 8 May 2024 12:45:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 86E736B0095; Wed, 8 May 2024 08:45:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 81F306B0096; Wed, 8 May 2024 08:45:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 699786B0098; Wed, 8 May 2024 08:45:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 4C48C6B0095 for ; Wed, 8 May 2024 08:45:30 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C16411A0C80 for ; Wed, 8 May 2024 12:45:29 +0000 (UTC) X-FDA: 82095199578.04.893A618 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf28.hostedemail.com (Postfix) with ESMTP id 67B7AC0017 for ; Wed, 8 May 2024 12:45:27 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=LBvDwF+4; spf=pass (imf28.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=1715172327; 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=nKOPWRtfFPemzFcBua7c8IERdqoqRoxeJZphMP7/WDk=; b=lTdY5PLzNa/ZF6hHtjctmKZHBJV7l+FFTpMAKz8he8cxj2obsh7TpU+dy6gC5gZnbnwn09 tF5amM6dKRcW2DbcK/OEEJkZ/Mmf/n+x6/x+XMMfVW1bk+ZadtcrGT5zALBZJO2WxiQ4l8 HYgsDQH+M8wBgicU++7mSlZkP2YuK3Y= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=LBvDwF+4; spf=pass (imf28.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=1715172327; a=rsa-sha256; cv=none; b=GHhraG8AhrApOKlFL5/YVYiqQcI1pJ51rBC9TOcUu4aK2B3l4tFoBoSj/cJPAd3qVrRU4o aKNjmpdKVQwJU0JLtKtHR6rfFQKPZKXlPl0sEQ1q5Iw0HMd220aaiYN4mLxNrpzMuCUHGg ZONJEgJRcdMrEDPfvbsKE0OFoW597qs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1715172326; 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=nKOPWRtfFPemzFcBua7c8IERdqoqRoxeJZphMP7/WDk=; b=LBvDwF+4Zi9B2WuQVNS1uz3h81ITcbHKuJ0eDoAGJXQ3U8AvFNpDypTVdML6X7DCzkpUhV NMkHpX2vN7g31bTABVb+vY7HGSJIn+/HLEAkrFFr8eFMw68zEof4i8yOzO+SAx/APUqTut /TnnzROPX+zM8AwPpQ5wnWeMg+2iExg= 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-664-lArJ4UmdPsO20M0wC-eL6w-1; Wed, 08 May 2024 08:45:23 -0400 X-MC-Unique: lArJ4UmdPsO20M0wC-eL6w-1 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-34dd570f48cso2591799f8f.3 for ; Wed, 08 May 2024 05:45:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715172322; x=1715777122; 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=nKOPWRtfFPemzFcBua7c8IERdqoqRoxeJZphMP7/WDk=; b=NroC0Uhmqh05auAkZouPwDr3lbKXCyE0NqPlDX8SfNl2BRnDoD8mXlNteY77G2vRlO TcIYu5311trWq/l9Le9xEyHOinZsPgpIcOven7pJlRtyMD6iASSSPA7vtzmvRByGGOAT CTU+u6unyg14ZIpQlr90yfK+enUyQ0hYL4dAdVyIWZQK5oVZzkmFbILOzkmp1mdgXJIX RIIrHJ0R3vy/9gV1MrjbL2bhVyYO6hW/6gwhJc1BztX+VzhmeRo6YztpO9mpR2SjnWBY JL5fqJlXqJ/cRAjHlAdI/dU5VcK68g12owDp/SRWo7NwBmNIploitPuxP+0Hxy7l3dxT yUZw== X-Forwarded-Encrypted: i=1; AJvYcCUMhnFc+IGkCfFNzMHR/vkVzoVG3RGbo9zaq79gtR6tdh7l6BryYWwoNekmLp+zBccQwUiNo+c09DUdetCjTEpNvTw= X-Gm-Message-State: AOJu0Yxq59tuMe7NWRnUttbqqLk/ryqPSOTcIrjknS/EzaXMacxFGjIG kEBhWLTPww1s+LIrQ0O9HOU4PD2TzxjRpv4zG9ntgVrSbNiUic2BIM3tX5i3I/jAIrvufN5AGNz uRkrXWWACM7U/E61nihthVASzIDzIUDTG2RuJEQgOVkp8J5kU X-Received: by 2002:adf:f7cb:0:b0:34d:b03c:9a99 with SMTP id ffacd0b85a97d-34fcaddf963mr1975343f8f.2.1715172322037; Wed, 08 May 2024 05:45:22 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFPIOWgDYDc8RPU4fQZPvnZmnDKhsbapctXF8d+7yMjU/pSkHCX/Lkj9HsDnJ5JKF5sUHuckw== X-Received: by 2002:adf:f7cb:0:b0:34d:b03c:9a99 with SMTP id ffacd0b85a97d-34fcaddf963mr1975312f8f.2.1715172321487; Wed, 08 May 2024 05:45:21 -0700 (PDT) Received: from ?IPV6:2003:cb:c707:3100:35c3:fc4b:669f:9ff9? (p200300cbc707310035c3fc4b669f9ff9.dip0.t-ipconnect.de. [2003:cb:c707:3100:35c3:fc4b:669f:9ff9]) by smtp.gmail.com with ESMTPSA id j3-20020a056000124300b0034de3098980sm15309823wrx.97.2024.05.08.05.45.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 May 2024 05:45:21 -0700 (PDT) Message-ID: Date: Wed, 8 May 2024 14:45:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 5/8] mm: shmem: add multi-size THP sysfs interface for anonymous shmem To: Ryan Roberts , Baolin Wang , akpm@linux-foundation.org, hughd@google.com Cc: willy@infradead.org, ioworker0@gmail.com, wangkefeng.wang@huawei.com, ying.huang@intel.com, 21cnbao@gmail.com, shy828301@gmail.com, ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <6b4afed1ef26dbd08ae9ec58449b329564dcef3e.1714978902.git.baolin.wang@linux.alibaba.com> <30329a82-45b9-4e78-8c48-bd56af113786@arm.com> <0b3735bc-2ad7-44f8-808b-37fc90d57199@linux.alibaba.com> <928c73de-76b0-40d6-a0c3-23d72270ac5c@redhat.com> <28f311ec-9b46-4f28-991c-ac74177acf32@redhat.com> <5c2c70fd-a291-4ca4-b229-dc54e92b3471@arm.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: <5c2c70fd-a291-4ca4-b229-dc54e92b3471@arm.com> X-Mimecast-Spam-Score: 0 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: 67B7AC0017 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: k1rbaog3wdmfs38ttfaq7abuyi675px4 X-HE-Tag: 1715172327-957040 X-HE-Meta: U2FsdGVkX1+IqD3DaDqvhlWDl+0fYkic75WAvnr3IMIrzcugriS4OzbNwFbqicMXlyZjwsJf5Dz8iFyeJqJSkUEJgdBR9gA24eec+v7i0Im9JTieVlAEhUkn6Jp5SqjGQmjwsV4o72akl05bTud4ffwui9Lx74NHgI28uTXFfpKXzFkebjrGakiIBMmiMu/uzPYLM/d/OtitnHkRcOz9m3fra+vKq7WZTmnvZxAvNaOQrlrglcoviJDVDlTqq+qwXK2SFawhO3s0U5dlGaOUdQSlDorzkHJZ6o/UwssnOLuUNF0Q0akbyg2WS925Oze+nIiLXw3JzXll6CLHM6gwjm+XCFlH3NSvDjHv0zERAT4Fdz72zXb8ipklYeAAYKQgsmugABAXE6BWHHpD6XFo+6hgkvTny+B84hC+ndkVZ6V39gnr0Yo8KiDvEsjd0pcNvWPKs1POUc6myyZN8EkzjRDEeNhhsnZ7arVKuLgRZZFQzftf0Zc6Li+Y4/YpqMuqhpycIfk5ZGKDInbdZOQpJqJbYLvOtUg3NWxPZ3TH1x3xMeyaOzE5w1UC0BqCJmxuBzkLoeOsEnhWudJF0JfQoldEa1RC5W2Nt2l2RrwbIKlQW8v+MQLLyXZEswhh8lR9UGT6hqsFqhwQJ7iu4+e8v16YExaZiUASCfT8gYdLyHj/LRYrGf/BlxNXt7Yg2gMfN0+jzrq8sDBHond5aQtM24jrn5HjTFtEAX4mEKg/DDDw9TGvnmuplvJLi37KYBFZqqMtiteACslpv4UkAW2ilKxblpPGUWuJq4Q4VV3DWNzL/shWNUkGHuX/PS6h2izIJ5UQBA9b8oRZkPzuWLh4p2OAaFhvOeez4MjNiw8Pv66YjZvN/vgDXVRIEwgBSMp4z5zLSxk58WN1fQXazm074JOTylGsGUcqojHwtP5q1VNbjPUJzjhDDe7jvFq4B/iTsE0wwdgbYbOypcmIM0p m0THtRF0 vePHNBVH59ZhpAr+wpJn3w6m7RGBqRGqy9k0ky9WnaAET0CD6z8am3MZR8HDB5R/c2JpJtcPyXEPLZ4ydZwXJ4LjUFDwuBp3xgbHJ36f7q9T/zZpDa7hPJoBjZPmeuxdEtaIGczXFw1HWABrR9BhKhqGvo46SSGlcbZTJSK2GVswET34lh3GQUuq7EdTemIxM0Msz2SZ0ZIIvlmBuIm7meHabnb4Oc40laEbnPkusj7kRs9rxu6xn0t5qdtvN3dmZ8mouz+kebQjRdZkHBWnfUR1op17yuZQEdse2RXChWjYWY2h8rySDb6Vu63k0BlMyiDZ8OTOZw/h0qeg95kvnfppOBuBnCWvRv0uceFaxu5tC0eUF4RqJFVQpo7lPjN45v8VWqsNK5khNnyncvWlgF7m218DRtfFneiWWpDJsB3YqEX2LDz1hPeByRRXgZQPavcMr8EOV6Pl3S9tfyxCSNWOnjUWtzE1mOQcH 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 08.05.24 14:43, Ryan Roberts wrote: > On 08/05/2024 13:10, David Hildenbrand wrote: >> On 08.05.24 14:02, David Hildenbrand wrote: >>> On 08.05.24 11:02, Ryan Roberts wrote: >>>> On 08/05/2024 08:12, David Hildenbrand wrote: >>>>> On 08.05.24 09:08, David Hildenbrand wrote: >>>>>> On 08.05.24 06:45, Baolin Wang wrote: >>>>>>> >>>>>>> >>>>>>> On 2024/5/7 18:52, Ryan Roberts wrote: >>>>>>>> On 06/05/2024 09:46, Baolin Wang wrote: >>>>>>>>> To support the use of mTHP with anonymous shmem, add a new sysfs interface >>>>>>>>> 'shmem_enabled' in the '/sys/kernel/mm/transparent_hugepage/hugepages-kB/' >>>>>>>>> directory for each mTHP to control whether shmem is enabled for that mTHP, >>>>>>>>> with a value similar to the top level 'shmem_enabled', which can be set to: >>>>>>>>> "always", "inherit (to inherit the top level setting)", "within_size", >>>>>>>>> "advise", >>>>>>>>> "never", "deny", "force". These values follow the same semantics as the top >>>>>>>>> level, except the 'deny' is equivalent to 'never', and 'force' is >>>>>>>>> equivalent >>>>>>>>> to 'always' to keep compatibility. >>>>>>>> >>>>>>>> We decided at [1] to not allow 'force' for non-PMD-sizes. >>>>>>>> >>>>>>>> [1] >>>>>>>> https://lore.kernel.org/linux-mm/533f37e9-81bf-4fa2-9b72-12cdcb1edb3f@redhat.com/ >>>>>>>> >>>>>>>> However, thinking about this a bit more, I wonder if the decision we made to >>>>>>>> allow all hugepages-xxkB/enabled controls to take "inherit" was the wrong >>>>>>>> one. >>>>>>>> Perhaps we should have only allowed the PMD-sized enable=inherit (this is >>>>>>>> just >>>>>>>> for legacy back compat after all, I don't think there is any use case where >>>>>>>> changing multiple mTHP size controls atomically is actually useful). >>>>>>>> Applying >>>>>>> >>>>>>> Agree. This is also our usage of 'inherit'. >>>>> >>>>> Missed that one: there might be use cases in the future once we would start >>>>> defaulting to "inherit" for all knobs (a distro might default to that) and >>>>> default-enable THP in the global knob. Then, it would be easy to disable any >>>>> THP >>>>> by disabling the global knob. (I think that's the future we're heading to, >>>>> where >>>>> we'd have an "auto" mode that can be set on the global toggle). >>>>> >>>>> But I am just making up use cases ;) I think it will be valuable and just doing >>>>> it consistently now might be cleaner. >>>> >>>> I agree that consistency between enabled and shmem_enabled is top priority. And >>>> yes, I had forgotten about the glorious "auto" future. So probably continuing >>>> all sizes to select "inherit" is best. >>>> >>>> But for shmem_enabled, that means we need the following error checking: >>>> >>>>    - It is an error to set "force" for any size except PMD-size >>>> >>>>    - It is an error to set "force" for the global control if any size except >>>> PMD- >>>>      size is set to "inherit" >>>> >>>>    - It is an error to set "inherit" for any size except PMD-size if the global >>>>      control is set to "force". >>>> >>>> Certainly not too difficult to code and prove to be correct, but not the nicest >>>> UX from the user's point of view when they start seeing errors. >>>> >>>> I think we previously said this would likely be temporary, and if/when tmpfs >>>> gets mTHP support, we could simplify and allow all sizes to be set to "force". >>>> But I wonder if tmpfs would ever need explicit mTHP control? Maybe it would be >>>> more suited to the approach the page cache takes to transparently ramp up the >>>> folio size as it faults more in. (Just saying there is a chance that this error >>>> checking becomes permanent). >>> >>> Note that with shmem you're inherently facing the same memory waste >>> issues etc as you would with anonymous memory. (sometimes even worse, if >>> you're running shmem that's configured to be unswappable!). >> >> Also noting that memory waste is not really a problem when a write to a shmem >> file allocates a large folio that stays within boundaries of that write; issues >> only pop up if you end up over-allocating, especially, during page faults where >> you have not that much clue about what to do (single address, no real range >> provided). >> >> There is the other issue that wasting large chunks of contiguous memory on stuff >> that barely benefits from it. With memory that maybe never gets evicted, there >> is no automatic "handing back" of that memory to the system to be used by >> something else. With ordinary files, that's a bit different. But I did not look >> closer into that issue yet, it's one of the reasons MADV_HUGEPAGE was added IIRC. > > OK understood. Although, with tmpfs you're not going to mmap it then randomly > extend the file through page faults - mmap doesn't permit that, I don't think? > So presumably the user must explicitly set the size of the file first? Are you > suggesting there are a lot of use cases where a large tmpfs file is created, > mmaped then only accessed sparsely? I don't know about "a lot of use cases", but for VMs that's certainly how it's used. -- Cheers, David / dhildenb